CASE STUDY:
Improving Performance and Morale with Cloud Native
@@ -66,7 +66,7 @@ The company has a large infrastructure: Ope
+
-
+
-
+
"For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."
@@ -74,7 +74,7 @@ featured: false
-
+
“There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly.”
diff --git a/content/en/case-studies/ant-financial/index.html b/content/en/case-studies/ant-financial/index.html
index 92b46526de..1711ef97b8 100644
--- a/content/en/case-studies/ant-financial/index.html
+++ b/content/en/case-studies/ant-financial/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -50,7 +50,7 @@ featured: false
To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced Docker containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
-
CASE STUDY:
Ant Financial’s Hypergrowth Strategy Using Kubernetes
@@ -50,7 +50,7 @@ featured: false
To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced Docker containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
+
-
+
diff --git a/content/en/case-studies/appdirect/index.html b/content/en/case-studies/appdirect/index.html
index 16d93cce5c..ca6b0b8fe9 100644
--- a/content/en/case-studies/appdirect/index.html
+++ b/content/en/case-studies/appdirect/index.html
@@ -12,7 +12,7 @@ quote: >
We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem.
---
-
+
CASE STUDY:
@@ -53,7 +53,7 @@ quote: >
-
CASE STUDY:
AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess
@@ -53,7 +53,7 @@ quote: >
+
-
+
-
+
“Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”
@@ -84,7 +84,7 @@ quote: >
-
+
-
+
“As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”
@@ -91,7 +91,7 @@ quote: >
-
+
-
+
"When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."
@@ -75,7 +75,7 @@ quote: >
-
+
"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event"
diff --git a/content/en/case-studies/bose/index.html b/content/en/case-studies/bose/index.html
index d22de2187a..c77f416c13 100644
--- a/content/en/case-studies/bose/index.html
+++ b/content/en/case-studies/bose/index.html
@@ -11,7 +11,7 @@ quote: >
The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.
---
-
+
CASE STUDY:
@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
CASE STUDY:
Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes
@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
+
-
+
diff --git a/content/en/case-studies/capital-one/index.html b/content/en/case-studies/capital-one/index.html
index 773db4869e..f95fb2acc7 100644
--- a/content/en/case-studies/capital-one/index.html
+++ b/content/en/case-studies/capital-one/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
css: /css/style_case_studies.css
---
-
+
CASE STUDY:
@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
-
CASE STUDY:
Supporting Fast Decisioning Applications with Kubernetes
@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
+
-
+
diff --git a/content/en/case-studies/cern/index.html b/content/en/case-studies/cern/index.html
index 9bd7970245..48e965d7fb 100644
--- a/content/en/case-studies/cern/index.html
+++ b/content/en/case-studies/cern/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
logo: cern_featured_logo.png
---
-
+
-
+
-
+
diff --git a/content/en/case-studies/chinaunicom/index.html b/content/en/case-studies/chinaunicom/index.html
index 296b2ce1fc..4479d60e67 100644
--- a/content/en/case-studies/chinaunicom/index.html
+++ b/content/en/case-studies/chinaunicom/index.html
@@ -8,7 +8,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -51,7 +51,7 @@ featured: false
-
CASE STUDY:
China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency
and Lower IT Costs
@@ -51,7 +51,7 @@ featured: false
and Lower IT Costs
+
-
+
diff --git a/content/en/case-studies/city-of-montreal/index.html b/content/en/case-studies/city-of-montreal/index.html
index 151ce44b21..55378c649e 100644
--- a/content/en/case-studies/city-of-montreal/index.html
+++ b/content/en/case-studies/city-of-montreal/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -50,7 +50,7 @@ featured: false
The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
-
CASE STUDY:
City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed Architecture with Kubernetes
@@ -50,7 +50,7 @@ featured: false
The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
+
-
+
diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html
index 3ad0812d24..27ef1c77ed 100644
--- a/content/en/case-studies/denso/index.html
+++ b/content/en/case-studies/denso/index.html
@@ -12,7 +12,7 @@ quote: >
---
-
-
+
"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
@@ -79,7 +79,7 @@ quote: >
-
+
"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."
diff --git a/content/en/case-studies/ibm/index.html b/content/en/case-studies/ibm/index.html
index 54e941c9cb..e9a78a9443 100644
--- a/content/en/case-studies/ibm/index.html
+++ b/content/en/case-studies/ibm/index.html
@@ -9,7 +9,7 @@ logo: ibm_featured_logo.svg
featured: false
---
-
+
CASE STUDY:
@@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
- CASE STUDY:
Building an Image Trust Service on Kubernetes with Notary and TUF
+
-
+
diff --git a/content/en/case-studies/ing/index.html b/content/en/case-studies/ing/index.html
index 6e2648a455..943daec2de 100644
--- a/content/en/case-studies/ing/index.html
+++ b/content/en/case-studies/ing/index.html
@@ -11,7 +11,7 @@ quote: >
---
-
+
CASE STUDY:
@@ -58,7 +58,7 @@ quote: >
-
CASE STUDY:
Driving Banking Innovation with Cloud Native
@@ -58,7 +58,7 @@ quote: >
+
-
+
diff --git a/content/en/case-studies/jd-com/index.html b/content/en/case-studies/jd-com/index.html
index 636f226339..aed12fc54b 100644
--- a/content/en/case-studies/jd-com/index.html
+++ b/content/en/case-studies/jd-com/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -51,7 +51,7 @@ featured: false
-
CASE STUDY:
JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale
@@ -51,7 +51,7 @@ featured: false
+
-
+
diff --git a/content/en/case-studies/naic/index.html b/content/en/case-studies/naic/index.html
index d40dd19c77..3deb91e480 100644
--- a/content/en/case-studies/naic/index.html
+++ b/content/en/case-studies/naic/index.html
@@ -9,7 +9,7 @@ logo: naic_featured_logo.png
featured: false
---
-
+
CASE STUDY:
@@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
- CASE STUDY:
A Culture and Technology Transition Enabled by Kubernetes
+
-
+
diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html
index d4cc89590d..bd606e7314 100644
--- a/content/en/case-studies/nav/index.html
+++ b/content/en/case-studies/nav/index.html
@@ -8,7 +8,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -52,7 +52,7 @@ featured: false
-
CASE STUDY:
How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes
@@ -52,7 +52,7 @@ featured: false
+
-
+
diff --git a/content/en/case-studies/nerdalize/index.html b/content/en/case-studies/nerdalize/index.html
index 127d95c375..2756ce431c 100644
--- a/content/en/case-studies/nerdalize/index.html
+++ b/content/en/case-studies/nerdalize/index.html
@@ -6,7 +6,7 @@ cid: caseStudies
css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
-
CASE STUDY:
Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes
@@ -47,7 +47,7 @@ featured: false
After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
+
-
+
“One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”
- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html index a62ade486f..6cba5579ab 100644 --- a/content/en/case-studies/netease/index.html +++ b/content/en/case-studies/netease/index.html @@ -9,7 +9,7 @@ featured: false --- -
- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html index a62ade486f..6cba5579ab 100644 --- a/content/en/case-studies/netease/index.html +++ b/content/en/case-studies/netease/index.html @@ -9,7 +9,7 @@ featured: false --- -
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After considering building its own orchestration solution, NetEase decided to base its private cloud platform on Kubernetes. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng.
- CASE STUDY:
How NetEase Leverages Kubernetes to Support Internet Business Worldwide
+
-
+
"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
- Li Lanqing, Kubernetes Developer, NetEase diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html index c65b5fe883..53dbd06a55 100644 --- a/content/en/case-studies/newyorktimes/index.html +++ b/content/en/case-studies/newyorktimes/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
- Li Lanqing, Kubernetes Developer, NetEase diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html index c65b5fe883..53dbd06a55 100644 --- a/content/en/case-studies/newyorktimes/index.html +++ b/content/en/case-studies/newyorktimes/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+
CASE STUDY:
@@ -64,7 +64,7 @@ css: /css/style_case_studies.css
-
CASE STUDY:
The New York Times: From Print to the Web to Cloud Native
@@ -64,7 +64,7 @@ css: /css/style_case_studies.css
+
-
+
"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
diff --git a/content/en/case-studies/nokia/index.html b/content/en/case-studies/nokia/index.html
index d8aaafc7f5..f824685327 100644
--- a/content/en/case-studies/nokia/index.html
+++ b/content/en/case-studies/nokia/index.html
@@ -8,7 +8,7 @@ logo: nokia_featured_logo.png
---
-
+
CASE STUDY:
@@ -51,7 +51,7 @@ logo: nokia_featured_logo.png
-
CASE STUDY:
Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
@@ -51,7 +51,7 @@ logo: nokia_featured_logo.png
+
-
+
diff --git a/content/en/case-studies/nordstrom/index.html b/content/en/case-studies/nordstrom/index.html
index 5385c2473d..788453de35 100644
--- a/content/en/case-studies/nordstrom/index.html
+++ b/content/en/case-studies/nordstrom/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
css: /css/style_case_studies.css
---
-
+
CASE STUDY:
CASE STUDY:
Finding Millions in Potential Savings in a Tough Retail Climate
@@ -60,7 +60,7 @@ css: /css/style_case_studies.css
-
+
-
+
diff --git a/content/en/case-studies/northwestern-mutual/index.html b/content/en/case-studies/northwestern-mutual/index.html
index dac0ef0d66..47b4bbc7be 100644
--- a/content/en/case-studies/northwestern-mutual/index.html
+++ b/content/en/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.
-
+
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html
index 6a930f945c..79ac9bf3a8 100644
--- a/content/en/case-studies/ocado/index.html
+++ b/content/en/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
+
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with
+
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html
index 040f704efa..1b95ec5f35 100644
--- a/content/en/case-studies/openAI/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html
index ddb567afb3..78f70228e5 100644
--- a/content/en/case-studies/pearson/index.html
+++ b/content/en/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."
-
+
-
+
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html
index 637f891b3e..8d032c7a8b 100644
--- a/content/en/case-studies/pingcap/index.html
+++ b/content/en/case-studies/pingcap/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
PingCAP Bets on Cloud Native for Its TiDB Database Platform
@@ -52,7 +52,7 @@ featured: false
Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-
+
-
+
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html
index 0aa2381aa1..e4be7031bb 100644
--- a/content/en/case-studies/pinterest/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html
index 03bbc51173..2f0beda5ae 100644
--- a/content/en/case-studies/prowise/index.html
+++ b/content/en/case-studies/prowise/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion
@@ -50,7 +50,7 @@ featured: false
The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
+
-
+
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html
index 62501c4f5b..2863ceac75 100644
--- a/content/en/case-studies/ricardo-ch/index.html
+++ b/content/en/case-studies/ricardo-ch/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
@@ -48,7 +48,7 @@ featured: false
To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
+
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH
diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html
index 4a99d28fb3..86ebe15f91 100644
--- a/content/en/case-studies/slamtec/index.html
+++ b/content/en/case-studies/slamtec/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-
+
-
+
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html
index a11527c2d9..349ed8c2de 100644
--- a/content/en/case-studies/slingtv/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html
index 64708a20f8..becf486413 100644
--- a/content/en/case-studies/sos/index.html
+++ b/content/en/case-studies/sos/index.html
@@ -8,7 +8,7 @@ logo: sos_featured_logo.png
---
-
+
CASE STUDY:
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
+
-
+
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html
index 85e7fc1e86..63243b08f6 100644
--- a/content/en/case-studies/spotify/index.html
+++ b/content/en/case-studies/spotify/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
-
+
-
+
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html
index d2b2a18c92..27340835f4 100644
--- a/content/en/case-studies/squarespace/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html
index 0a35de2b1a..ad990356ff 100644
--- a/content/en/case-studies/thredup/index.html
+++ b/content/en/case-studies/thredup/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -49,7 +49,7 @@ featured: false
"We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-
+
-
+
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html
index 4ca7aa1bbc..c2ac2a2a72 100644
--- a/content/en/case-studies/vsco/index.html
+++ b/content/en/case-studies/vsco/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
@@ -48,7 +48,7 @@ featured: false
-
+
-
+
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html
index aa41b7cb44..fbb86bdd24 100644
--- a/content/en/case-studies/woorank/index.html
+++ b/content/en/case-studies/woorank/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with
12 Engineers—At 30% Less Cost
@@ -50,7 +50,7 @@ featured: false
-
+
-
+
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html
index 95f323d5ae..1c09503bfb 100644
--- a/content/en/case-studies/workiva/index.html
+++ b/content/en/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
-
+
-
+
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
-
+
@@ -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
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html
index 498dc0ec73..c07443249a 100644
--- a/content/en/case-studies/ygrene/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
index 39af4fb779..c3b51f3acf 100644
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -64,7 +64,7 @@ Before choosing a guide, here are some considerations:
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
### Securing the kubelet
- * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
+ * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index 26fc1194df..5cdd070e0f 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -303,6 +303,9 @@ to get a mapping of UIDs to names for both FlowSchemas and
PriorityLevelConfigurations.
## Observability
+
+### Metrics
+
When you enable the API Priority and Fairness feature, the kube-apiserver
exports additional metrics. Monitoring these can help you determine whether your
configuration is inappropriately throttling important traffic, or find
@@ -365,9 +368,65 @@ poorly-behaved workloads that may be harming system health.
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
+### Debug endpoints
+When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports.
+- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
+ workload-low, 0, true, false, 0, 0,
+ global-default, 0, true, false, 0, 0,
+ exempt, , , , , ,
+ catch-all, 0, true, false, 0, 0,
+ system, 0, true, false, 0, 0,
+ leader-election, 0, true, false, 0, 0,
+ workload-high, 0, true, false, 0, 0,
+ ```
+- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_queues
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart,
+ workload-high, 0, 0, 0, 0.0000,
+ workload-high, 1, 0, 0, 0.0000,
+ workload-high, 2, 0, 0, 0.0000,
+ ...
+ leader-election, 14, 0, 0, 0.0000,
+ leader-election, 15, 0, 0, 0.0000,
+ ```
+
+- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_requests
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime,
+ exempt, , , , , ,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
+ ```
+
+ In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation.
+
+ You can get a more detailed listing with a command like this:
+ ```shell
+ kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ ```
+
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index b052dd3a15..d0485a4342 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
kubectl scale deployment/my-nginx --replicas=1
```
```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
```
Now you only have one pod managed by the deployment.
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 29044be250..6779ee984a 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -12,7 +12,7 @@ understand exactly how it is expected to work. There are 4 distinct networking
problems to address:
1. Highly-coupled container-to-container communications: this is solved by
- [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications.
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications.
2. Pod-to-Pod communications: this is the primary focus of this document.
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 89a361a350..f40c99fbc4 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -224,7 +224,7 @@ data has the following advantages:
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
closing watches for config maps marked as immutable.
-To use this feature, enable the `ImmutableEmphemeralVolumes`
+To use this feature, enable the `ImmutableEphemeralVolumes`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
your Secret or ConfigMap `immutable` field to `true`. For example:
```yaml
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index db78a8304e..f791510b39 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -132,11 +132,9 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
+ - name: app
+ image: images.my-company.example/app:v4
env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
resources:
requests:
memory: "64Mi"
@@ -144,8 +142,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -330,18 +328,15 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
- env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
+ - name: app
+ image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 7eae77ac46..01e1f64d19 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -217,7 +217,7 @@ makes Pod P eligible to preempt Pods on another Node.
#### Graceful termination of preemption victims
When Pods are preempted, the victims get their
-[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
They have that much time to finish their work and exit. If they don't, they are
killed. This graceful termination period creates a time gap between the point
that the scheduler preempts Pods and the time when the pending Pod (P) can be
@@ -230,7 +230,7 @@ priority Pods to zero or a small number.
#### PodDisruptionBudget is supported, but not guaranteed
-A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/)
+A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
allows application owners to limit the number of Pods of a replicated application
that are down simultaneously from voluntary disruptions. Kubernetes supports
PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index 386e4d00bb..c8e93e93db 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
### Hook handler implementations
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index a01e8d84f9..415d920b40 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -129,7 +129,7 @@ example, run these on your desktop/laptop:
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
-For production clusers, use a configuration management tool so that you can apply this
+For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
deleted file mode 100644
index 7f81439c41..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Poseidon-Firmament Scheduler
-content_type: concept
-weight: 80
----
-
-
-
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-
-
-
-
-
-
-## Introduction
-
-Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions.
-
-Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements.
-
-Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers.
-
-Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages:
-
-- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale.
- The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs).
-- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads.
-- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run.
-- The Poseidon-Firmament scheduler supports scheduling complex rule constraints.
-
-## How the Poseidon-Firmament scheduler works
-
-Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-...
-spec:
- schedulerName: poseidon
-...
-```
-
-## Batch scheduling
-
-As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs.
-
-Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most:
-
-1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous.
-2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs).
-
-## Feature state
-
-Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases.
-
-{{< caution >}}
-Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail.
-{{< /caution >}}
-
-## Feature comparison {#feature-comparison-matrix}
-
-{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}}
-|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes|
-|--- |--- |--- |--- |
-|Node Affinity/Anti-Affinity|Y|Y||
-|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.|
-|Taints & Tolerations|Y|Y||
-|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.|
-|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.|
-|Colocation Interference Avoidance|N|N||
-|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.|
-|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.|
-|Gang Scheduling|N|Y||
-|Support for Pre-bound Persistence Volume Scheduling|Y|Y||
-|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N||
-|High Availability|Y|N||
-|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.|
-|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.|
-|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y||
-{{< /table >}}
-
-## Installation
-
-The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster.
-
-## Performance comparison
-
-{{< note >}}
- Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler.
-{{< /note >}}
-
-Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks:
-
-1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed.
-2. There is limited opportunities for amortizing work across pods because they are considered for placement individually.
-
-These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-
-
-## {{% heading "whatsnext" %}}
-
-* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
-* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
-* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
-* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index b3b6960358..42d12425b7 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -25,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-
-
## API changes
@@ -87,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Versioning is done at the API level rather than at the resource or field level to ensure that the
API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -157,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 1f4f4e7509..ab447cdcd6 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 0f2965a7a3..9829692126 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup
Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 4d3a9255d4..d7fc53a4d0 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -235,7 +235,7 @@ IngressClass resource will ensure that new Ingresses without an
If you have more than one IngressClass marked as the default for your cluster,
the admission controller prevents creating new Ingress objects that don't have
an `ingressClassName` specified. You can resolve this by ensuring that at most 1
-IngressClasess are marked as default in your cluster.
+IngressClasses are marked as default in your cluster.
{{< /caution >}}
## Types of Ingress
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 79d260d52a..9819334ce8 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -1356,7 +1356,7 @@ persistent volume:
of a volume. This map must correspond to the map returned in the
`volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as
defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
- The map is passed to the CSI driver via the `volume_attributes` field in the
+ The map is passed to the CSI driver via the `volume_context` field in the
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
`NodePublishVolumeRequest`.
- `controllerPublishSecretRef`: A reference to the secret object containing
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index 7f1b5c4630..c3d8cf36d8 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev
The `.spec.template` is one of the required fields in `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
labels (see [pod selector](#pod-selector)).
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 67582e9041..2c2fd8c7c2 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -13,8 +13,8 @@ weight: 30
-A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
-[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
+A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}}
+{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}.
You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
@@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th
{{< /note >}}
-
-
## Use Case
@@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib
The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
-The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
-`apiVersion` or `kind`.
+The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
@@ -1155,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-### Rollback To
-
-Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
-
### Revision History Limit
A Deployment's revision history is stored in the ReplicaSets it controls.
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index a20951a35e..79cc905f58 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy`
field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
"Foreground", or "Background".
-Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
-This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
-Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you
-specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1`
-group version, dependent objects are deleted by default.
-
Here's an example that deletes dependents in background:
```shell
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index 21e8aceb64..81c1280943 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a Job must specify appropriate
labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 2cc8284940..d59c09fc6b 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).
diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md
old mode 100755
new mode 100644
index a105f18fb3..c7408721b7
--- a/content/en/docs/concepts/workloads/pods/_index.md
+++ b/content/en/docs/concepts/workloads/pods/_index.md
@@ -1,5 +1,271 @@
---
-title: "Pods"
+reviewers:
+- erictune
+title: Pods
+content_type: concept
weight: 10
+no_list: true
+card:
+ name: concepts
+ weight: 60
---
+
+
+_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
+
+A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
+{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification
+for how to run the containers. A Pod's contents are always co-located and
+co-scheduled, and run in a shared context. A Pod models an
+application-specific "logical host": it contains one or more application
+containers which are relatively tightly coupled.
+In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
+
+As well as application containers, a Pod can contain
+[init containers](/docs/concepts/workloads/pods/init-containers/) that run
+during Pod startup. You can also inject
+[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/)
+for debugging if your cluster offers this.
+
+
+
+## What is a Pod?
+
+{{< note >}}
+While Kubernetes supports more
+{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}}
+than just Docker, [Docker](https://www.docker.com/) is the most commonly known
+runtime, and it helps to describe Pods using some terminology from Docker.
+{{< /note >}}
+
+The shared context of a Pod is a set of Linux namespaces, cgroups, and
+potentially other facets of isolation - the same things that isolate a Docker
+container. Within a Pod's context, the individual applications may have
+further sub-isolations applied.
+
+In terms of Docker concepts, a Pod is similar to a group of Docker containers
+with shared namespaces and shared filesystem volumes.
+
+## Using Pods
+
+Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
+term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
+If your Pods need to track state, consider the
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
+
+Pods in a Kubernetes cluster are used in two main ways:
+
+* **Pods that run a single container**. The "one-container-per-Pod" model is the
+ most common Kubernetes use case; in this case, you can think of a Pod as a
+ wrapper around a single container; Kubernetes manages Pods rather than managing
+ the containers directly.
+* **Pods that run multiple containers that need to work together**. A Pod can
+ encapsulate an application composed of multiple co-located containers that are
+ tightly coupled and need to share resources. These co-located containers
+ form a single cohesive unit of service—for example, one container serving data
+ stored in a shared volume to the public, while a separate _sidecar_ container
+ refreshes or updates those files.
+ The Pod wraps these containers, storage resources, and an ephemeral network
+ identity together as a single unit.
+
+ {{< note >}}
+ Grouping multiple co-located and co-managed containers in a single Pod is a
+ relatively advanced use case. You should use this pattern only in specific
+ instances in which your containers are tightly coupled.
+ {{< /note >}}
+
+Each Pod is meant to run a single instance of a given application. If you want to
+scale your application horizontally (to provide more overall resources by running
+more instances), you should use multiple Pods, one for each instance. In
+Kubernetes, this is typically referred to as _replication_.
+Replicated Pods are usually created and managed as a group by a workload resource
+and its {{< glossary_tooltip text="controller" term_id="controller" >}}.
+
+See [Pods and controllers](#pods-and-controllers) for more information on how
+Kubernetes uses workload resources, and their controllers, to implement application
+scaling and auto-healing.
+
+### How Pods manage multiple containers
+
+Pods are designed to support multiple cooperating processes (as containers) that form
+a cohesive unit of service. The containers in a Pod are automatically co-located and
+co-scheduled on the same physical or virtual machine in the cluster. The containers
+can share resources and dependencies, communicate with one another, and coordinate
+when and how they are terminated.
+
+For example, you might have a container that
+acts as a web server for files in a shared volume, and a separate "sidecar" container
+that updates those files from a remote source, as in the following diagram:
+
+{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
+
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
+
+Pods natively provide two kinds of shared resources for their constituent containers:
+[networking](#pod-networking) and [storage](#pod-storage).
+
+## Working with Pods
+
+You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
+is because Pods are designed as relatively ephemeral, disposable entities. When
+a Pod gets created (directly by you, or indirectly by a
+{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is
+scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster.
+The Pod remains on that node until the Pod finishes execution, the Pod object is deleted,
+the Pod is *evicted* for lack of resources, or the node fails.
+
+{{< note >}}
+Restarting a container in a Pod should not be confused with restarting a Pod. A Pod
+is not a process, but an environment for running container(s). A Pod persists until
+it is deleted.
+{{< /note >}}
+
+When you create the manifest for a Pod object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+### Pods and controllers
+
+You can use workload resources to create and manage multiple Pods for you. A controller
+for the resource handles replication and rollout and automatic healing in case of
+Pod failure. For example, if a Node fails, a controller notices that Pods on that
+Node have stopped working and creates a replacement Pod. The scheduler places the
+replacement Pod onto a healthy Node.
+
+Here are some examples of workload resources that manage one or more Pods:
+
+* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
+* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
+
+### Pod templates
+
+Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
+from a _pod template_ and manage those Pods on your behalf.
+
+PodTemplates are specifications for creating Pods, and are included in workload resources such as
+[Deployments](/docs/concepts/workloads/controllers/deployment/),
+[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
+
+Each controller for a workload resource uses the `PodTemplate` inside the workload
+object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
+workload resource you used to run your app.
+
+The sample below is a manifest for a simple Job with a `template` that starts one
+container. The container in that Pod prints a message then pauses.
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: hello
+spec:
+ template:
+ # This is the pod template
+ spec:
+ containers:
+ - name: hello
+ image: busybox
+ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+ restartPolicy: OnFailure
+ # The pod template ends here
+```
+
+Modifying the pod template or switching to a new pod template has no effect on the
+Pods that already exist. Pods do not receive template updates directly. Instead,
+a new Pod is created to match the revised pod template.
+
+For example, the deployment controller ensures that the running Pods match the current
+pod template for each Deployment object. If the template is updated, the Deployment has
+to remove the existing Pods and create new Pods based on the updated template. Each workload
+resource implements its own rules for handling changes to the Pod template.
+
+On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
+directly observe or manage any of the details around pod templates and updates; those
+details are abstracted away. That abstraction and separation of concerns simplifies
+system semantics, and makes it feasible to extend the cluster's behavior without
+changing existing code.
+
+## Resource sharing and communication
+
+Pods enable data sharing and communication among their constituent
+containters.
+
+### Storage in Pods {#pod-storage}
+
+A Pod can specify a set of shared storage
+{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers
+in the Pod can access the shared volumes, allowing those containers to
+share data. Volumes also allow persistent data in a Pod to survive
+in case one of the containers within needs to be restarted. See
+[Storage](/docs/concepts/storage/) for more information on how
+Kubernetes implements shared storage and makes it available to Pods.
+
+### Pod networking
+
+Each Pod is assigned a unique IP address for each address family. Every
+container in a Pod shares the network namespace, including the IP address and
+network ports. Inside a Pod (and **only** then), the containers that belong to the Pod
+can communicate with one another using `localhost`. When containers in a Pod communicate
+with entities *outside the Pod*,
+they must coordinate how they use the shared network resources (such as ports).
+Within a Pod, containers share an IP address and port space, and
+can find each other via `localhost`. The containers in a Pod can also communicate
+with each other using standard inter-process communications like SystemV semaphores
+or POSIX shared memory. Containers in different Pods have distinct IP addresses
+and can not communicate by IPC without
+[special configuration](/docs/concepts/policy/pod-security-policy/).
+Containers that want to interact with a container running in a different Pod can
+use IP networking to comunicate.
+
+Containers within the Pod see the system hostname as being the same as the configured
+`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
+section.
+
+## Privileged mode for containers
+
+Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
+Processes within a privileged container get almost the same privileges that are available to processes outside a container.
+
+{{< note >}}
+Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
+{{< /note >}}
+
+## Static Pods
+
+_Static Pods_ are managed directly by the kubelet daemon on a specific node,
+without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
+observing them.
+Whereas most Pods are managed by the control plane (for example, a
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static
+Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
+
+Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
+The main use for static Pods is to run a self-hosted control plane: in other words,
+using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
+
+The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
+on the Kubernetes API server for each static Pod.
+This means that the Pods running on a node are visible on the API server,
+but cannot be controlled from there.
+
+## {{% heading "whatsnext" %}}
+
+* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
+* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
+* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
+ configure different Pods with different container runtime configurations.
+* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
+* Pod is a top-level resource in the Kubernetes REST API.
+ The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+ object definition describes the object in detail.
+* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
+
+To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
+ * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+ * [Borg](https://research.google.com/pubs/pub43438.html)
+ * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+ * [Omega](https://research.google/pubs/pub41684/)
+ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md
index 589bde5668..0810b6fec7 100644
--- a/content/en/docs/concepts/workloads/pods/disruptions.md
+++ b/content/en/docs/concepts/workloads/pods/disruptions.md
@@ -11,17 +11,15 @@ weight: 60
This guide is for application owners who want to build
highly available applications, and thus need to understand
-what types of Disruptions can happen to Pods.
+what types of disruptions can happen to Pods.
-It is also for Cluster Administrators who want to perform automated
+It is also for cluster administrators who want to perform automated
cluster actions, like upgrading and autoscaling clusters.
-
-
-## Voluntary and Involuntary Disruptions
+## Voluntary and involuntary disruptions
Pods do not disappear until someone (a person or a controller) destroys them, or
there is an unavoidable hardware or system software error.
@@ -48,7 +46,7 @@ Administrator. Typical application owner actions include:
- updating a deployment's pod template causing a restart
- directly deleting a pod (e.g. by accident)
-Cluster Administrator actions include:
+Cluster administrator actions include:
- [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade.
- Draining a node from a cluster to scale the cluster down (learn about
@@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa
deleting deployments or pods bypasses Pod Disruption Budgets.
{{< /caution >}}
-## Dealing with Disruptions
+## Dealing with disruptions
Here are some ways to mitigate involuntary disruptions:
@@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and
Your cluster administrator or hosting provider should have documented what level of voluntary
disruptions, if any, to expect.
-Kubernetes offers features to help run highly available applications at the same
-time as frequent voluntary disruptions. We call this set of features
-*Disruption Budgets*.
-
-## How Disruption Budgets Work
+## Pod disruption budgets
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
-An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
-A PDB limits the number of pods of a replicated application that are down simultaneously from
-voluntary disruptions. For example, a quorum-based application would
+Kubernetes offers features to help you run highly available applications even when you
+introduce frequent voluntary disruptions.
+
+As an application owner, you can create a PodDisruptionBudget (PDB) for each application.
+A PDB limits the number of Pods of a replicated application that are down simultaneously from
+voluntary disruptions. For example, a quorum-based application would
like to ensure that the number of replicas running is never brought below the
number needed for a quorum. A web front end might want to
ensure that the number of replicas serving load never falls below a certain
percentage of the total.
Cluster managers and hosting providers should use tools which
-respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
-instead of directly deleting pods or deployments. Examples are the `kubectl drain` command
-and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
+respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
+instead of directly deleting pods or deployments.
-When a cluster administrator wants to drain a node
-they use the `kubectl drain` command. That tool tries to evict all
-the pods on the machine. The eviction request may be temporarily rejected,
-and the tool periodically retries all failed requests until all pods
-are terminated, or until a configurable timeout is reached.
+For example, the `kubectl drain` subcommand lets you mark a node as going out of
+service. When you run `kubectl drain`, the tool tries to evict all of the Pods on
+the Node you're taking out of service. The eviction request that `kubectl` submits on
+your behalf may be temporarily rejected, so the tool periodically retries all failed
+requests until all Pods on the target node are terminated, or until a configurable timeout
+is reached.
A PDB specifies the number of replicas that an application can tolerate having, relative to how
many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is
supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time,
-then the Eviction API will allow voluntary disruption of one, but not two pods, at a time.
+then the Eviction API will allow voluntary disruption of one (but not two) pods at a time.
The group of pods that comprise the application is specified using a label selector, the same
as the one used by the application's controller (deployment, stateful-set, etc).
-The "intended" number of pods is computed from the `.spec.replicas` of the pods controller.
-The controller is discovered from the pods using the `.metadata.ownerReferences` of the object.
+The "intended" number of pods is computed from the `.spec.replicas` of the workload resource
+that is managing those pods. The control plane discovers the owning workload resource by
+examining the `.metadata.ownerReferences` of the Pod.
PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from
occurring, but they do count against the budget.
Pods which are deleted or unavailable due to a rolling upgrade to an application do count
-against the disruption budget, but controllers (like deployment and stateful-set)
-are not limited by PDBs when doing rolling upgrades -- the handling of failures
-during application updates is configured in the controller spec.
-(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+against the disruption budget, but workload resources (such as Deployment and StatefulSet)
+are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures
+during application updates is configured in the spec for the specific workload resource.
-When a pod is evicted using the eviction API, it is gracefully terminated (see
-`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
+When a pod is evicted using the eviction API, it is gracefully
+[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the
+`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
-## PDB Example
+## PodDisruptionBudget example {#pdb-example}
Consider a cluster with 3 nodes, `node-1` through `node-3`.
The cluster is running several applications. One of them has 3 replicas initially called
@@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
+* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
+ including steps to maintain its availability during the rollout.
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index d72265faf5..2b292d376d 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -6,16 +6,60 @@ weight: 30
-{{< comment >}}Updated: 4/14/2015{{< /comment >}}
-{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
-
-This page describes the lifecycle of a Pod.
+This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting
+in the `Pending` [phase](#pod-phase), moving through `Running` if at least one
+of its primary containers starts OK, and then through either the `Succeeded` or
+`Failed` phases depending on whether any container in the Pod terminated in failure.
+Whilst a Pod is running, the kubelet is able to restart containers to handle some
+kind of faults. Within a Pod, Kubernetes tracks different container
+[states](#container-states) and handles
+In the Kubernetes API, Pods have both a specification and an actual status. The
+status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
+You can also inject [custom readiness information](#pod-readiness-gate) into the
+condition data for a Pod, if that is useful to your application.
+Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime.
+Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops
+or is [terminated](#pod-termination).
+## Pod lifetime
+
+Like individual application containers, Pods are considered to be relatively
+ephemeral (rather than durable) entities. Pods are created, assigned a unique
+ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
+to nodes where they remain until termination (according to restart policy) or
+deletion.
+If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
+are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
+
+Pods do not, by themselves, self-heal. If a Pod is scheduled to a
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
+or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
+survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
+higher-level abstraction, called a
+{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of
+managing the relatively disposable Pod instances.
+
+A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
+that Pod can be replaced by a new, near-identical Pod, with even the same name i
+desired, but with a different UID.
+
+When something is said to have the same lifetime as a Pod, such as a
+{{< glossary_tooltip term_id="volume" text="volume" >}},
+that means that the thing exists as long as that specific Pod (with that exact UID)
+exists. If that Pod is deleted for any reason, and even if an identical replacement
+is created, the related thing (a volume, in this example) is also destroyed and
+created anew.
+
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+
+*A multi-container Pod that contains a file puller and a
+web server that uses a persistent volume for shared storage between the containers.*
+
## Pod phase
A Pod's `status` field is a
@@ -24,7 +68,7 @@ object, which has a `phase` field.
The phase of a Pod is a simple, high-level summary of where the Pod is in its
lifecycle. The phase is not intended to be a comprehensive rollup of observations
-of Container or Pod state, nor is it intended to be a comprehensive state machine.
+of container or Pod state, nor is it intended to be a comprehensive state machine.
The number and meanings of Pod phase values are tightly guarded.
Other than what is documented here, nothing should be assumed about Pods that
@@ -34,188 +78,106 @@ Here are the possible values for `phase`:
Value | Description
:-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
-`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting.
-`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted.
-`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
-`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.
+`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
+`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
+`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
+`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
+`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
+
+If a node dies or is disconnected from the rest of the cluster, Kubernetes
+applies a policy for setting the `phase` of all Pods on the lost node to Failed.
+
+## Container states
+
+As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of
+each container inside a Pod. You can use
+[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to
+trigger events to run at certain points in a container's lifecycle.
+
+Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}
+assigns a Pod to a Node, the kubelet starts creating containers for that Pod
+using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
+There are three possible container states: `Waiting`, `Running`, and `Terminated`.
+
+To the check state of a Pod's containers, you can use
+`kubectl describe pod `. The output shows the state for each container
+within that Pod.
+
+Each state has a specific meaning:
+
+### `Waiting` {#container-state-waiting}
+
+If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+A container in the `Waiting` state is still running the operations it requires in
+order to complete start up: for example, pulling the container image from a container
+image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
+data.
+When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see
+a Reason field to summarize why the container is in that state.
+
+### `Running` {#container-state-running}
+
+The `Running` status indicates that a container is executing without issues. If there
+was a `postStart` hook configured, it has already executed and executed. When you use
+`kubectl` to query a Pod with a container that is `Running`, you also see information
+about when the container entered the `Running` state.
+
+### `Terminated` {#container-state-terminated}
+
+A container in the `Terminated` state has begin execution and has then either run to
+completion or has failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, and exit code, and the start and
+finish time for that container's period of execution.
+
+If a container has a `preStop` hook configured, that runs before the container enters
+the `Terminated` state.
+
+## Container restart policy {#restart-policy}
+
+The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure,
+and Never. The default value is Always.
+
+The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
+refers to restarts of the containers by the kubelet on the same node. After containers
+in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
+40s, …), that is capped at five minutes. Once a container has executed with no problems
+for 10 minutes without any problems, the kubelet resets the restart backoff timer for
+that container.
## Pod conditions
A Pod has a PodStatus, which has an array of
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)
-through which the Pod has or has not passed. Each element of the PodCondition
-array has six possible fields:
+through which the Pod has or has not passed:
-* The `lastProbeTime` field provides a timestamp for when the Pod condition
- was last probed.
+* `PodScheduled`: the Pod has been scheduled to a node.
+* `ContainersReady`: all containers in the Pod are ready.
+* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
+ have started successfully.
+* `Ready`: the Pod is able to serve requests and should be added to the load
+ balancing pools of all matching Services.
-* The `lastTransitionTime` field provides a timestamp for when the Pod
- last transitioned from one status to another.
-
-* The `message` field is a human-readable message indicating details
- about the transition.
-
-* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition.
-
-* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`".
-
-* The `type` field is a string with the following possible values:
-
- * `PodScheduled`: the Pod has been scheduled to a node;
- * `Ready`: the Pod is able to serve requests and should be added to the load
- balancing pools of all matching Services;
- * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
- have started successfully;
- * `ContainersReady`: all containers in the Pod are ready.
+Field name | Description
+:--------------------|:-----------
+`type` | Name of this Pod condition.
+`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`".
+`lastProbeTime` | Timestamp of when the Pod condition was last probed.
+`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another.
+`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition.
+`message` | Human-readable message indicating details about the last status transition.
-
-## Container probes
-
-A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
-on a Container. To perform a diagnostic,
-the kubelet calls a
-[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
-the Container. There are three types of handlers:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
- Executes a specified command inside the Container. The diagnostic
- is considered successful if the command exits with a status code of 0.
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
- Performs a TCP check against the Container's IP address on
- a specified port. The diagnostic is considered successful if the port is open.
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
- Performs an HTTP Get request against the Container's IP
- address on a specified port and path. The diagnostic is considered successful
- if the response has a status code greater than or equal to 200 and less than 400.
-
-Each probe has one of three results:
-
-* Success: The Container passed the diagnostic.
-* Failure: The Container failed the diagnostic.
-* Unknown: The diagnostic failed, so no action should be taken.
-
-The kubelet can optionally perform and react to three kinds of probes on running
-Containers:
-
-* `livenessProbe`: Indicates whether the Container is running. If
- the liveness probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a liveness probe, the default state is `Success`.
-
-* `readinessProbe`: Indicates whether the Container is ready to service requests.
- If the readiness probe fails, the endpoints controller removes the Pod's IP
- address from the endpoints of all Services that match the Pod. The default
- state of readiness before the initial delay is `Failure`. If a Container does
- not provide a readiness probe, the default state is `Success`.
-
-* `startupProbe`: Indicates whether the application within the Container is started.
- All other probes are disabled if a startup probe is provided, until it succeeds.
- If the startup probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a startup probe, the default state is `Success`.
-
-### When should you use a liveness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If the process in your Container is able to crash on its own whenever it
-encounters an issue or becomes unhealthy, you do not necessarily need a liveness
-probe; the kubelet will automatically perform the correct action in accordance
-with the Pod's `restartPolicy`.
-
-If you'd like your Container to be killed and restarted if a probe fails, then
-specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
-
-### When should you use a readiness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If you'd like to start sending traffic to a Pod only when a probe succeeds,
-specify a readiness probe. In this case, the readiness probe might be the same
-as the liveness probe, but the existence of the readiness probe in the spec means
-that the Pod will start without receiving any traffic and only start receiving
-traffic after the probe starts succeeding.
-If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe.
-
-If you want your Container to be able to take itself down for maintenance, you
-can specify a readiness probe that checks an endpoint specific to readiness that
-is different from the liveness probe.
-
-Note that if you just want to be able to drain requests when the Pod is deleted,
-you do not necessarily need a readiness probe; on deletion, the Pod automatically
-puts itself into an unready state regardless of whether the readiness probe exists.
-The Pod remains in the unready state while it waits for the Containers in the Pod
-to stop.
-
-### When should you use a startup probe?
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s.
-You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.
-
-For more information about how to set up a liveness, readiness, startup probe, see
-[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-## Pod and Container status
-
-For detailed information about Pod Container status, see
-[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
-and
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-Note that the information reported as Pod status depends on the current
-[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-
-## Container States
-
-Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod.
-
-* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information.
-
- ```yaml
- ...
- State: Waiting
- Reason: ErrImagePull
- ...
- ```
-
-* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state.
-
- ```yaml
- ...
- State: Running
- Started: Wed, 30 Jan 2019 16:46:38 +0530
- ...
- ```
-
-* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed.
-
- ```yaml
- ...
- State: Terminated
- Reason: Completed
- Exit Code: 0
- Started: Wed, 30 Jan 2019 11:45:26 +0530
- Finished: Wed, 30 Jan 2019 11:45:26 +0530
- ...
- ```
-
-## Pod readiness {#pod-readiness-gate}
+### Pod readiness {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
Your application can inject extra feedback or signals into PodStatus:
-_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify
-a list of additional conditions that the kubelet evaluates for Pod readiness.
+_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to
+specify a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
-fields for the Pod. If Kubernetes cannot find such a
-condition in the `status.conditions` field of a Pod, the status of the condition
+fields for the Pod. If Kubernetes cannot find such a condition in the
+`status.conditions` field of a Pod, the status of the condition
is defaulted to "`False`".
Here is an example:
@@ -258,152 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only*
when both the following statements apply:
* All containers in the Pod are ready.
-* All conditions specified in `ReadinessGates` are `True`.
+* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
-`False`, the kubelet sets the Pod's condition to `ContainersReady`.
+`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
-## Restart policy
+## Container probes
-A PodSpec has a `restartPolicy` field with possible values Always, OnFailure,
-and Never. The default value is Always.
-`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only
-refers to restarts of the Containers by the kubelet on the same node. Exited
-Containers that are restarted by the kubelet are restarted with an exponential
-back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten
-minutes of successful execution. As discussed in the
-[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
-once bound to a node, a Pod will never be rebound to another node.
+A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
+performed periodically by the [kubelet](/docs/admin/kubelet/)
+on a Container. To perform a diagnostic,
+the kubelet calls a
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
+the container. There are three types of handlers:
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+ Executes a specified command inside the container. The diagnostic
+ is considered successful if the command exits with a status code of 0.
-## Pod lifetime
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+ Performs a TCP check against the Pod's IP address on
+ a specified port. The diagnostic is considered successful if the port is open.
-In general, Pods remain until a human or
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+ Performs an HTTP `GET` request against the Pod's IP
+ address on a specified port and path. The diagnostic is considered successful
+ if the response has a status code greater than or equal to 200 and less than 400.
+
+Each probe has one of three results:
+
+* `Success`: The container passed the diagnostic.
+* `Failure`: The container failed the diagnostic.
+* `Unknown`: The diagnostic failed, so no action should be taken.
+
+The kubelet can optionally perform and react to three kinds of probes on running
+containers:
+
+* `livenessProbe`: Indicates whether the container is running. If
+ the liveness probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a liveness probe, the default state is `Success`.
+
+* `readinessProbe`: Indicates whether the container is ready to respond to requests.
+ If the readiness probe fails, the endpoints controller removes the Pod's IP
+ address from the endpoints of all Services that match the Pod. The default
+ state of readiness before the initial delay is `Failure`. If a Container does
+ not provide a readiness probe, the default state is `Success`.
+
+* `startupProbe`: Indicates whether the application within the container is started.
+ All other probes are disabled if a startup probe is provided, until it succeeds.
+ If the startup probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a startup probe, the default state is `Success`.
+
+For more information about how to set up a liveness, readiness, or startup probe,
+see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+
+### When should you use a liveness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If the process in your container is able to crash on its own whenever it
+encounters an issue or becomes unhealthy, you do not necessarily need a liveness
+probe; the kubelet will automatically perform the correct action in accordance
+with the Pod's `restartPolicy`.
+
+If you'd like your container to be killed and restarted if a probe fails, then
+specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
+
+### When should you use a readiness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If you'd like to start sending traffic to a Pod only when a probe succeeds,
+specify a readiness probe. In this case, the readiness probe might be the same
+as the liveness probe, but the existence of the readiness probe in the spec means
+that the Pod will start without receiving any traffic and only start receiving
+traffic after the probe starts succeeding.
+If your container needs to work on loading large data, configuration files, or
+migrations during startup, specify a readiness probe.
+
+If you want your container to be able to take itself down for maintenance, you
+can specify a readiness probe that checks an endpoint specific to readiness that
+is different from the liveness probe.
+
+{{< note >}}
+If you just want to be able to drain requests when the Pod is deleted, you do not
+necessarily need a readiness probe; on deletion, the Pod automatically puts itself
+into an unready state regardless of whether the readiness probe exists.
+The Pod remains in the unready state while it waits for the containers in the Pod
+to stop.
+{{< /note >}}
+
+### When should you use a startup probe?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Startup probes are useful for Pods that have containers that take a long time to
+come into service. Rather than set a long liveness interval, you can configure
+a separate configuration for probing the container as it starts up, allowing
+a time longer than the liveness interval would allow.
+
+If your container usually starts in more than
+`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a
+startup probe that checks the same endpoint as the liveness probe. The default for
+`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to
+allow the container to start, without changing the default values of the liveness
+probe. This helps to protect against deadlocks.
+
+## Termination of Pods {#pod-termination}
+
+Because Pods represent processes running on nodes in the cluster, it is important to
+allow those processes to gracefully terminate when they are no longer needed (rather
+than being abruptly stopped with a `KILL` signal and having no chance to clean up).
+
+The design aim is for you to be able to request deletion and know when processes
+terminate, but also be able to ensure that deletes eventually complete.
+When you request deletion of a Pod, the cluster records and tracks the intended grace period
+before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in
+place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
+shutdown.
+
+Typically, the container runtime sends a a TERM signal is sent to the main process in each
+container. Once the grace period has expired, the KILL signal is sent to any remainig
+processes, and the Pod is then deleted from the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
+container runtime's management service is restarted while waiting for processes to terminate, the
+cluster retries from the start including the full original grace period.
+
+An example flow:
+
+1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
+ (30 seconds).
+1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
+ along with the grace period.
+ If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
+ "Terminating".
+ On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
+ as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
+ shutdown process.
+ 1. If one of the Pod's containers has defined a `preStop`
+ [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
+ runs that hook inside of the container. If the `preStop` hook is still running after the
+ grace period expires, the kubelet requests a small, one-off grace period extension of 2
+ seconds.
+ {{< note >}}
+ If the `preStop` hook needs longer to complete than the default grace period allows,
+ you must modify `terminationGracePeriodSeconds` to suit this.
+ {{< /note >}}
+ 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
+ container.
+ {{< note >}}
+ The containers in the Pod receive the TERM signal at different times and in an arbitrary
+ order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
+ {{< /note >}}
+1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that
+ shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent
+ a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured
+ {{< glossary_tooltip text="selector" term_id="selector" >}}.
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources
+ no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly
+ cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from
+ the list of endpoints as soon as the termination grace period _begins_.
+1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends
+ `SIGKILL` to any processes still running in any container in the Pod.
+ The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
+1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
+ to 0 (immediate deletion).
+1. The API server deletes the Pod's API object, which is then no longer visible from any client.
+
+### Forced Pod termination {#pod-termination-forced}
+
+{{< caution >}}
+Forced deletions can be potentially disruptiove for some workloads and their Pods.
+{{< /caution >}}
+
+By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
+the `--grace-period=` option which allows you to override the default and specify your
+own value.
+
+Setting the grace period to `0` forcibly and immediately deletes the Pod from the API
+server. If the pod was still running on a node, that forcible deletion triggers the kubelet to
+begin immediate cleanup.
+
+{{< note >}}
+You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+{{< /note >}}
+
+When a force deletion is performed, the API server does not wait for confirmation
+from the kubelet that the Pod has been terminated on the node it was running on. It
+removes the Pod in the API immediately so a new Pod can be created with the same
+name. On the node, Pods that are set to terminate immediately will still be given
+a small grace period before being force killed.
+
+If you need to force-delete Pods that are part of a StatefulSet, refer to the task
+documentation for
+[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+
+### Garbage collection of failed Pods {#pod-garbage-collection}
+
+For failed Pods, the API objects remain in the cluster's API until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process
explicitly removes them.
+
The control plane cleans up terminated Pods (with a phase of `Succeeded` or
`Failed`), when the number of Pods exceeds the configured threshold
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
This avoids a resource leak as Pods are created and terminated over time.
-There are different kinds of resources for creating Pods:
-
-- Use a {{< glossary_tooltip term_id="deployment" >}},
- {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}}
- for Pods that are not expected to terminate, for example, web servers.
-
-- Use a {{< glossary_tooltip term_id="job" >}}
- for Pods that are expected to terminate once their work is complete;
- for example, batch computations. Jobs are appropriate only for Pods with
- `restartPolicy` equal to OnFailure or Never.
-
-- Use a {{< glossary_tooltip term_id="daemonset" >}}
- for Pods that need to run one per eligible node.
-
-All workload resources contain a PodSpec. It is recommended to create the
-appropriate workload resource and let the resource's controller create Pods
-for you, rather than directly create Pods yourself.
-
-If a node dies or is disconnected from the rest of the cluster, Kubernetes
-applies a policy for setting the `phase` of all Pods on the lost node to Failed.
-
-## Examples
-
-### Advanced liveness probe example
-
-Liveness probes are executed by the kubelet, so all requests are made in the
-kubelet network namespace.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- labels:
- test: liveness
- name: liveness-http
-spec:
- containers:
- - args:
- - /server
- image: k8s.gcr.io/liveness
- livenessProbe:
- httpGet:
- # when "host" is not defined, "PodIP" will be used
- # host: my-host
- # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
- # scheme: HTTPS
- path: /healthz
- port: 8080
- httpHeaders:
- - name: X-Custom-Header
- value: Awesome
- initialDelaySeconds: 15
- timeoutSeconds: 1
- name: liveness
-```
-
-### Example states
-
- * Pod is running and has one Container. Container exits with success.
- * Log completion event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Pod `phase` becomes Succeeded.
- * Never: Pod `phase` becomes Succeeded.
-
- * Pod is running and has one Container. Container exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has two Containers. Container 1 exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Do not restart Container; Pod `phase` stays Running.
- * If Container 1 is not running, and Container 2 exits:
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has one Container. Container runs out of memory.
- * Container terminates in failure.
- * Log OOM event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Log failure event; Pod `phase` becomes Failed.
-
- * Pod is running, and a disk dies.
- * Kill all Containers.
- * Log appropriate event.
- * Pod `phase` becomes Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
- * Pod is running, and its node is segmented out.
- * Node controller waits for timeout.
- * Node controller sets Pod `phase` to Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
-
-
## {{% heading "whatsnext" %}}
-
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
* Get hands-on experience
- [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-
+ [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
+* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+and
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
deleted file mode 100644
index e963b7ace6..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-reviewers:
-- erictune
-title: Pod Overview
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 60
----
-
-
-This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-
-
-
-
-## Understanding Pods
-
-A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
-
-A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
-
-[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
-
-
-Pods in a Kubernetes cluster can be used in two main ways:
-
-* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
-* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-
-Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_.
-Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}.
-See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing.
-
-### How Pods manage multiple containers
-
-Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
-
-Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
-
-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
-
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-
-Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
-
-#### Networking
-
-Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
-
-#### Storage
-
-A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
-
-## Working with Pods
-
-You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails.
-
-{{< note >}}
-Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted.
-{{< /note >}}
-
-Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller.
-
-### Pods and controllers
-
-You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node.
-
-Here are some examples of workload resources that manage one or more Pods:
-
-* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
-* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
-* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
-
-
-## Pod templates
-
-Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
-from a pod template and manage those Pods on your behalf.
-
-PodTemplates are specifications for creating Pods, and are included in workload resources such as
-[Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
-[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
-
-Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app.
-
-The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: hello
-spec:
- template:
- # This is the pod template
- spec:
- containers:
- - name: hello
- image: busybox
- command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
- restartPolicy: OnFailure
- # The pod template ends here
-```
-
-Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template.
-
-For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template.
-
-On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
-
-
-
-## {{% heading "whatsnext" %}}
-
-* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
-* Learn more about Pod behavior:
- * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 650280a82f..9982ac7240 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,7 +1,7 @@
---
title: Pod Topology Spread Constraints
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index d87dc92cb2..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-reviewers:
-title: Pods
-content_type: concept
-weight: 20
----
-
-
-
-_Pods_ are the smallest deployable units of computing that can be created and
-managed in Kubernetes.
-
-
-
-
-
-
-## What is a Pod?
-
-A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
-{{< glossary_tooltip text="containers" term_id="container" >}} (such as
-Docker containers), with shared storage/network, and a specification
-for how to run the containers. A Pod's contents are always co-located and
-co-scheduled, and run in a shared context. A Pod models an
-application-specific "logical host" - it contains one or more application
-containers which are relatively tightly coupled — in a pre-container
-world, being executed on the same physical or virtual machine would mean being
-executed on the same logical host.
-
-While Kubernetes supports more container runtimes than just Docker, Docker is
-the most commonly known runtime, and it helps to describe Pods in Docker terms.
-
-The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a Docker
-container. Within a Pod's context, the individual applications may have
-further sub-isolations applied.
-
-Containers within a Pod share an IP address and port space, and
-can find each other via `localhost`. They can also communicate with each
-other using standard inter-process communications like SystemV semaphores or
-POSIX shared memory. Containers in different Pods have distinct IP addresses
-and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
-These containers usually communicate with each other via Pod IP addresses.
-
-Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
-as part of a Pod and are made available to be mounted into each application's
-filesystem.
-
-In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
-a group of Docker containers with shared namespaces and shared filesystem
-volumes.
-
-Like individual application containers, Pods are considered to be relatively
-ephemeral (rather than durable) entities. As discussed in
-[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
-scheduled to nodes where they remain until termination (according to restart
-policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
-scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
-"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
-with even the same name if desired, but with a new UID (see [replication
-controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
-
-When something is said to have the same lifetime as a Pod, such as a volume,
-that means that it exists as long as that Pod (with that UID) exists. If that
-Pod is deleted for any reason, even if an identical replacement is created, the
-related thing (e.g. volume) is also destroyed and created anew.
-
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
-
-*A multi-container Pod that contains a file puller and a
-web server that uses a persistent volume for shared storage between the containers.*
-
-## Motivation for Pods
-
-### Management
-
-Pods are a model of the pattern of multiple cooperating processes which form a
-cohesive unit of service. They simplify application deployment and management
-by providing a higher-level abstraction than the set of their constituent
-applications. Pods serve as unit of deployment, horizontal scaling, and
-replication. Colocation (co-scheduling), shared fate (e.g. termination),
-coordinated replication, resource sharing, and dependency management are
-handled automatically for containers in a Pod.
-
-### Resource sharing and communication
-
-Pods enable data sharing and communication among their constituents.
-
-The applications in a Pod all use the same network namespace (same IP and port
-space), and can thus "find" each other and communicate using `localhost`.
-Because of this, applications in a Pod must coordinate their usage of ports.
-Each Pod has an IP address in a flat shared networking space that has full
-communication with other physical computers and Pods across the network.
-
-Containers within the Pod see the system hostname as being the same as the configured
-`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
-section.
-
-In addition to defining the application containers that run in the Pod, the Pod
-specifies a set of shared storage volumes. Volumes enable data to survive
-container restarts and to be shared among the applications within the Pod.
-
-## Uses of pods
-
-Pods can be used to host vertically integrated application stacks (e.g. LAMP),
-but their primary motivation is to support co-located, co-managed helper
-programs, such as:
-
-* content management systems, file and data loaders, local cache managers, etc.
-* log and checkpoint backup, compression, rotation, snapshotting, etc.
-* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
-* proxies, bridges, and adapters
-* controllers, managers, configurators, and updaters
-
-Individual Pods are not intended to run multiple instances of the same
-application, in general.
-
-For a longer explanation, see [The Distributed System ToolKit: Patterns for
-Composite
-Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
-
-## Alternatives considered
-
-_Why not just run multiple programs in a single (Docker) container?_
-
-1. Transparency. Making the containers within the Pod visible to the
- infrastructure enables the infrastructure to provide services to those
- containers, such as process management and resource monitoring. This
- facilitates a number of conveniences for users.
-1. Decoupling software dependencies. The individual containers may be
- versioned, rebuilt and redeployed independently. Kubernetes may even support
- live updates of individual containers someday.
-1. Ease of use. Users don't need to run their own process managers, worry about
- signal and exit-code propagation, etc.
-1. Efficiency. Because the infrastructure takes on more responsibility,
- containers can be lighter weight.
-
-_Why not support affinity-based co-scheduling of containers?_
-
-That approach would provide co-location, but would not provide most of the
-benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
-simplified management.
-
-## Durability of pods (or lack thereof)
-
-Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
-
-In general, users shouldn't need to create Pods directly. They should almost
-always use controllers even for singletons, for example,
-[Deployments](/docs/concepts/workloads/controllers/deployment/).
-Controllers provide self-healing with a cluster scope, as well as replication
-and rollout management.
-Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
-can also provide support to stateful Pods.
-
-The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
-
-Pod is exposed as a primitive in order to facilitate:
-
-* scheduler and controller pluggability
-* support for pod-level operations without the need to "proxy" them via controller APIs
-* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
-* decoupling of controllers and services — the endpoint controller just watches Pods
-* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
-* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
-
-## Termination of Pods
-
-Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
-
-An example flow:
-
-1. User sends command to delete Pod, with default grace period (30s)
-1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
-1. Pod shows up as "Terminating" when listed in client commands
-1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
- 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete.
- 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
-1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
-1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
-1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
-
-By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
-You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
-
-### Force deletion of pods
-
-Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-
-Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-
-## Privileged mode for pod containers
-
-Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
-
-{{< note >}}
-Your container runtime must support the concept of a privileged container for this setting to be relevant.
-{{< /note >}}
-
-## API Object
-
-Pod is a top-level resource in the Kubernetes REST API.
-The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
-describes the object in detail.
-When creating the manifest for a Pod object, make sure the name specified is a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
-
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index f77e34a3f9..9cbb7bdff8 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -1,7 +1,7 @@
---
reviewers:
- jessfraz
-title: Pod Preset
+title: Pod Presets
content_type: concept
weight: 50
---
@@ -32,20 +32,20 @@ specific service do not need to know all the details about that service.
In order to use Pod presets in your cluster you must ensure the following:
-1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
- example, this can be done by including `settings.k8s.io/v1alpha1=true` in
- the `--runtime-config` option for the API server. In minikube add this flag
- `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
- starting the cluster.
-1. You have enabled the admission controller `PodPreset`. One way to doing this
- is to include `PodPreset` in the `--enable-admission-plugins` option value specified
- for the API server. In minikube, add this flag
-
- ```shell
- --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
- ```
-
- while starting the cluster.
+1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
+ example, this can be done by including `settings.k8s.io/v1alpha1=true` in
+ the `--runtime-config` option for the API server. In minikube add this flag
+ `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
+ starting the cluster.
+1. You have enabled the admission controller named `PodPreset`. One way to doing this
+ is to include `PodPreset` in the `--enable-admission-plugins` option value specified
+ for the API server. For example, if you use Minikube, add this flag:
+
+ ```shell
+ --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+ ```
+
+ while starting your cluster.
## How it works
@@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following:
modified by a `PodPreset`. The annotation is of the form
`podpreset.admission.kubernetes.io/podpreset-: ""`.
-Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be
-applied to zero or more pods. When a `PodPreset` is applied to one or more
-Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
-`VolumeMounts`, Kubernetes modifies the container spec for all containers in
-the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
+Each Pod can be matched by zero or more PodPresets; and each PodPreset can be
+applied to zero or more Pods. When a PodPreset is applied to one or more
+Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and
+`volumeMounts`, Kubernetes modifies the container spec for all containers in
+the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec.
{{< note >}}
A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
-- The `.spec.containers` field.
-- The `initContainers` field (requires Kubernetes version 1.14.0 or later).
+- The `.spec.containers` field
+- The `.spec.initContainers` field
{{< /note >}}
-### Disable Pod Preset for a Specific Pod
+### Disable Pod Preset for a specific pod
There may be instances where you wish for a Pod to not be altered by any Pod
-Preset mutations. In these cases, you can add an annotation in the Pod Spec
+preset mutations. In these cases, you can add an annotation in the Pod's `.spec`
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
-
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
-
-
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index d8f57e5e82..cd1b03efd4 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -28,41 +28,62 @@ Kubernetes documentation welcomes improvements from all contributors, new and ex
## Getting started
-Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community.
+Anyone can open an issue about documentation, or contribute a change with a
+pull request (PR) to the
+[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website).
+You need to be comfortable with
+[git](https://git-scm.com/) and
+[GitHub](https://lab.github.com/)
+to work effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
-3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
+1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+ and the website's [static site generator](https://gohugo.io).
+1. Make sure you understand the basic processes for
+ [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
+ [reviewing changes](/docs/contribute/review/reviewing-prs/).
Some tasks require more trust and more access in the Kubernetes organization.
-See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
+See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
roles and permissions.
## Your first contribution
-- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
-- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points.
-- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
-- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
-- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
+- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
+ learn about the different ways you can contribute.
+- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
+ for issues that make good entry points.
+- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
+ to existing documentation and learn more about filing issues in GitHub.
+- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other
+ Kubernetes community members for accuracy and language.
+- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and
+ [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Learn about [page content types](/docs/contribute/style/page-content-types/)
+ and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
-- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository.
+- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo)
+ of the repository.
- Document [features in a release](/docs/contribute/new-content/new-features/).
-- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities).
+- Participate in [SIG Docs](/docs/contribute/participate/), and become a
+ [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/).
+
- Start or help with a [localization](/docs/contribute/localization/).
## Get involved with SIG Docs
-[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project.
+[SIG Docs](/docs/contribute/participate/) is the group of contributors who
+publish and maintain Kubernetes documentation and the website. Getting
+involved with SIG Docs is a great way for Kubernetes contributors (feature
+development or otherwise) to have a large impact on the Kubernetes project.
SIG Docs communicates with different methods:
-- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to
+- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 4c6a3f415a..52ae7b0efd 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -13,13 +13,12 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-
-
## Propose improvements
-SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
+SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members)
+can propose improvements.
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
@@ -42,8 +41,8 @@ documentation testing might involve working with sig-testing.
## Coordinate docs for a Kubernetes release
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
-docs for a Kubernetes release.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can coordinate docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
@@ -73,8 +72,8 @@ rotated among SIG Docs approvers.
## Serve as a New Contributor Ambassador
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
-New Contributor Ambassadors.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve as New Contributor Ambassadors.
New Contributor Ambassadors welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
@@ -92,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
## Sponsor a new contributor
-SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
-new contributors.
+SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers)
+can sponsor new contributors.
After a new contributor has successfully submitted 5 substantive pull requests
to one or more Kubernetes repositories, they are eligible to apply for
-[membership](/docs/contribute/participating#members) in the Kubernetes
-organization. The contributor's membership needs to be backed by two sponsors
-who are already reviewers.
+[membership](/docs/contribute/participate/roles-and-responsibilities/#members)
+in the Kubernetes organization. The contributor's membership needs to be
+backed by two sponsors who are already reviewers.
New docs contributors can request sponsors by asking in the #sig-docs channel
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
@@ -111,7 +110,8 @@ membership in the Kubernetes organization.
## Serve as a SIG Co-chair
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve a term as a co-chair of SIG Docs.
### Prerequisites
@@ -120,7 +120,12 @@ Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
-- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
+- Understand how other Kubernetes SIGs and repositories affect the SIG Docs
+ workflow, including:
+ [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+ [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
+ plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
+ [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
### Responsibilities
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index a1fed1642e..ea6065472e 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -15,21 +15,16 @@ like
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
This topic does not show how to generate the
-[kubectl](/docs/reference/generated/kubectl/kubectl/)
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
options reference page. For instructions on how to generate the kubectl options
reference page, see
-[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
+[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/).
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Setting up the local repositories
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index f68d81dfb4..f2ec01d8e8 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -194,16 +194,14 @@ The use of `make docker-serve` is deprecated. Please use `make container-serve`
In `` run `git add` and `git commit` to commit the change.
Submit your changes as a
-[pull request](/docs/contribute/start/) to the
+[pull request](/docs/contribute/new-content/open-a-pr/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-
## {{% heading "whatsnext" %}}
-
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
index a777fb77e5..c719920813 100644
--- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
+++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
@@ -18,4 +18,5 @@
- You need to know how to create a pull request to a GitHub repository.
This involves creating your own fork of the repository. For more
- information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
+ information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo).
+
diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md
index df5cdbb95f..0790f7925a 100644
--- a/content/en/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md
@@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Getting the docs repository
@@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps:
the sections in the `kubectl` command reference.
When the generated files are in your local clone of the ``
-repository, you can submit them in a [pull request](/docs/contribute/start/)
+repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/)
to ``.
## Configuration file format
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 0c698305b9..1ae4796522 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -183,7 +183,7 @@ Description | URLs
-----|-----
Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
-Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
+Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 98998d7f74..d511360e22 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -1,6 +1,5 @@
---
title: Opening a pull request
-slug: new-content
content_type: concept
weight: 10
card:
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index e9ef332430..b1f7e4f20a 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
+- In addition to the standard Hugo shortcodes, we use a number of
+ [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+ language has its own folder with a two-letter code determined by the
+ [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
+ example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md
index a99eaf464e..a5c0f2880a 100644
--- a/content/en/docs/contribute/participate/_index.md
+++ b/content/en/docs/contribute/participate/_index.md
@@ -20,18 +20,18 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a
pull request (PR), and anyone is welcome to file issues about content or comment
on pull requests in progress.
-You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
-[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater
-access and entail certain responsibilities for approving and committing changes.
-See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members),
+[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or
+[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers).
+These roles require greater access and entail certain responsibilities for
+approving and committing changes. See
+[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for more information on how membership works within the Kubernetes community.
The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
-
-
## SIG Docs chairperson
@@ -58,8 +58,9 @@ There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/
Each can be referenced with their `@name` in GitHub comments to communicate with
everyone in that group.
-Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals,
-the automation uses information from `OWNERS` files.
+Sometimes Prow and GitHub teams overlap without matching exactly. For
+assignment of issues, pull requests, and to support PR approvals, the
+automation uses information from `OWNERS` files.
### OWNERS files and front-matter
@@ -114,6 +115,6 @@ SIG Docs approvers. Here's how it works.
For more information about contributing to the Kubernetes documentation, see:
-- [Contributing new content](/docs/contribute/overview/)
+- [Contributing new content](/docs/contribute/new-content/overview/)
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
index 6538e813df..c2ab60a811 100644
--- a/content/en/docs/contribute/participate/pr-wranglers.md
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -36,16 +36,16 @@ The following queries are helpful when wrangling.
After working through these queries, the remaining list of PRs to review is usually small.
These queries exclude localization PRs. All queries are against the main branch except the last one.
-- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
+- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
-- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
+- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
-- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
+- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
Lists PRs that need an `/approve` comment to merge.
-- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
-- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
### When to close Pull Requests
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md
new file mode 100644
index 0000000000..8ebe7a1303
--- /dev/null
+++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md
@@ -0,0 +1,237 @@
+---
+title: Roles and responsibilities
+content_type: concept
+weight: 10
+---
+
+
+
+Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow,
+you can apply for different levels of membership in the community.
+These roles allow you to take on more responsibility within the community.
+Each role requires more time and commitment. The roles are:
+
+- Anyone: regular contributors to the Kubernetes documentation
+- Members: can assign and triage issues and provide non-binding review on pull requests
+- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
+- Approvers: can lead reviews on documentation and merge changes
+
+
+
+## Anyone
+
+Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
+
+Anyone can:
+
+- Open an issue in any [Kubernetes](https://github.com/kubernetes/)
+ repository, including
+ [`kubernetes/website`](https://github.com/kubernetes/website)
+- Give non-binding feedback on a pull request
+- Contribute to a localization
+- Suggest improvements on [Slack](https://slack.k8s.io/) or the
+ [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
+
+- Open a pull request to improve existing content, add new content, or write a blog post or case study
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+
+For more information, see [contributing new content](/docs/contribute/new-content/).
+
+## Members
+
+A member is someone who has submitted multiple pull requests to
+`kubernetes/website`. Members are a part of the
+[Kubernetes GitHub organization](https://github.com/kubernetes).
+
+Members can:
+
+- Do everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
+
+ {{< note >}}
+ Using `/lgtm` triggers automation. If you want to provide non-binding
+ approval, simply commenting "LGTM" works too!
+ {{< /note >}}
+
+- Use the `/hold` comment to block merging for a pull request
+- Use the `/assign` comment to assign a reviewer to a pull request
+- Provide non-binding review on pull requests
+- Use automation to triage and categorize issues
+- Document new features
+
+### Becoming a member
+
+After submitting at least 5 substantial pull requests and meeting the other
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
+
+1. Find two [reviewers](#reviewers) or [approvers](#approvers) to
+ [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your
+ membership.
+
+ Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
+ [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+ {{< note >}}
+ Don't send a direct email or Slack direct message to an individual
+ SIG Docs member. You must request sponsorship before submitting your application.
+ {{< /note >}}
+
+1. Open a GitHub issue in the
+ [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the
+ **Organization Membership Request** issue template.
+
+1. Let your sponsors know about the GitHub issue. You can either:
+ - Mention their GitHub username in an issue (`@`)
+ - Send them the issue link using Slack or email.
+
+ Sponsors will approve your request with a `+1` vote. Once your sponsors
+ approve the request, a Kubernetes GitHub admin adds you as a member.
+ Congratulations!
+
+ If your membership request is not accepted you will receive feedback.
+ After addressing the feedback, apply again.
+
+1. Accept the invitation to the Kubernetes GitHub organization in your email account.
+
+ {{< note >}}
+ GitHub sends the invitation to the default email address in your account.
+ {{< /note >}}
+
+## Reviewers
+
+Reviewers are responsible for reviewing open pull requests. Unlike member
+feedback, you must address reviewer feedback. Reviewers are members of the
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub team.
+
+Reviewers can:
+
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Review pull requests and provide binding feedback
+
+ {{< note >}}
+ To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
+ {{< /note >}}
+
+- Edit user-facing strings in code
+- Improve code comments
+
+You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
+
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
+review from a specific person by commenting: `/assign
+[@_github_handle]`.
+
+If the assigned reviewer has not commented on the PR, another reviewer can
+step in. You can also assign technical reviewers as needed.
+
+### Using `/lgtm`
+
+LGTM stands for "Looks good to me" and indicates that a pull request is
+technically accurate and ready to merge. All PRs need a `/lgtm` comment from a
+reviewer and a `/approve` comment from an approver to merge.
+
+A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
+
+### Becoming a reviewer
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
+you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
+separately for reviewer status in SIG Docs.
+
+To apply:
+
+1. Open a pull request that adds your GitHub user name to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
+ in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
+ {{< /note >}}
+
+1. Assign the PR to one or more SIG-Docs approvers (user names listed under
+ `sig-docs-{language}-owners`).
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## Approvers
+
+Approvers review and approve pull requests for merging. Approvers are members of the
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub teams.
+
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling
+
+If the PR already has a `/lgtm`, or if the approver also comments with
+`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a
+`/lgtm` on a change that doesn't need additional technical review.
+
+
+### Approving pull requests
+
+Approvers and SIG Docs leads are the only ones who can merge pull requests
+into the website repository. This comes with certain responsibilities.
+
+- Approvers can use the `/approve` command, which merges PRs into the repo.
+
+ {{< warning >}}
+ A careless merge can break the site, so be sure that when you merge something, you mean it.
+ {{< /warning >}}
+
+- Make sure that proposed changes meet the
+ [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
+
+ If you ever have a question, or you're not sure about something, feel free
+ to call for additional review.
+
+- Verify that Netlify tests pass before you `/approve` a PR.
+
+ 
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md
deleted file mode 100644
index f4cca67155..0000000000
--- a/content/en/docs/contribute/participate/roles-and-responsibilties.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Roles and responsibilities
-content_type: concept
-weight: 10
----
-
-
-
-Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
-These roles allow you to take on more responsibility within the community.
-Each role requires more time and commitment. The roles are:
-
-- Anyone: regular contributors to the Kubernetes documentation
-- Members: can assign and triage issues and provide non-binding review on pull requests
-- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
-- Approvers: can lead reviews on documentation and merge changes
-
-
-
-## Anyone
-
-Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
-
-Anyone can:
-
-- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
-- Give non-binding feedback on a pull request
-- Contribute to a localization
-- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-
-- Open a pull request to improve existing content, add new content, or write a blog post or case study
-- Create diagrams, graphics assets, and embeddable screencasts and videos
-
-For more information, see [contributing new content](/docs/contribute/new-content/).
-
-## Members
-
-A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
-
-Members can:
-
-- Do everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
-
- {{< note >}}
- Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
- {{< /note >}}
-- Use the `/hold` comment to block merging for a pull request
-- Use the `/assign` comment to assign a reviewer to a pull request
-- Provide non-binding review on pull requests
-- Use automation to triage and categorize issues
-- Document new features
-
-### Becoming a member
-
-After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
-
-1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
-
- Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member. You must request sponsorship before submitting your application.
- {{< /note >}}
-
-2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-
-3. Let your sponsors know about the GitHub issue. You can either:
- - Mention their GitHub username in an issue (`@`)
- - Send them the issue link using Slack or email.
-
- Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
-
- If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
-
-4. Accept the invitation to the Kubernetes GitHub organization in your email account.
-
- {{< note >}}
- GitHub sends the invitation to the default email address in your account.
- {{< /note >}}
-
-## Reviewers
-
-Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
-
-Reviewers can:
-
-- Do everything listed under [Anyone](#anyone) and [Members](#members)
-- Review pull requests and provide binding feedback
-
- {{< note >}}
- To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
- {{< /note >}}
-
-- Edit user-facing strings in code
-- Improve code comments
-
-You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
-
-### Assigning reviewers to pull requests
-
-Automation assigns reviewers to all pull requests. You can request a
-review from a specific person by commenting: `/assign
-[@_github_handle]`.
-
-If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
-
-### Using `/lgtm`
-
-LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
-
-A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
-
-### Becoming a reviewer
-
-When you meet the
-[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs.
-
-To apply:
-
-1. Open a pull request that adds your GitHub user name to a section of the
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
-in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
- {{< /note >}}
-
-2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## Approvers
-
-Approvers review and approve pull requests for merging. Approvers are members of the
-[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
-
-Approvers can do the following:
-
-- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
-- Publish contributor content by approving and merging pull requests using the `/approve` comment
-- Propose improvements to the style guide
-- Propose improvements to docs tests
-- Propose improvements to the Kubernetes website or other tooling
-
-If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review.
-
-
-### Approving pull requests
-
-Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
-
-- Approvers can use the `/approve` command, which merges PRs into the repo.
-
- {{< warning >}}
- A careless merge can break the site, so be sure that when you merge something, you mean it.
- {{< /warning >}}
-
-- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
-
- If you ever have a question, or you're not sure about something, feel free to call for additional review.
-
-- Verify that Netlify tests pass before you `/approve` a PR.
-
-
-
-- Visit the Netlify page preview for a PR to make sure things look good before approving.
-
-- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/).
-for more details.
-
-### Becoming an approver
-
-When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
-
-To apply:
-
-1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
- {{< /note >}}
-
-2. Assign the PR to one or more current SIG Docs approvers.
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## {{% heading "whatsnext" %}}
-
-- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
\ No newline at end of file
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 0cddbcba6a..82a05bdb86 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -8,7 +8,9 @@ weight: 20
-SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
+SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
+[Approvers](/docs/contribute/participate/#approvers) do a few extra things
+when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -19,9 +21,6 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-
-
-
## Reviewing a PR
@@ -202,9 +201,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
-[Kubernetes slack](http://slack.k8s.io/). You can also search
+[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index 3c271aa44f..ff6ef9d709 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
-[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-
-
+ [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Understand the different
+ [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/)
+ in the Kubernetes documentation community.
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index 569ca8d72c..0de4a381a3 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -10,9 +10,9 @@ weight: 10
This page contains guidelines for Kubernetes documentation.
If you have questions about what's allowed, join the #sig-docs channel in
-[Kubernetes Slack](http://slack.k8s.io/) and ask!
+[Kubernetes Slack](https://slack.k8s.io/) and ask!
-You can register for Kubernetes Slack at http://slack.k8s.io/.
+You can register for Kubernetes Slack at https://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
@@ -67,7 +67,7 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes
### More information
-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
+If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index e4a6d703ad..ab949be7fc 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -232,7 +232,7 @@ Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
-{{< tab name="JSON File" include="podtemplate" />}}
+{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
@@ -242,6 +242,6 @@ Renders to:
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/contribute/style/page-content-types/).
-* Learn about [creating a pull request](/docs/contribute/new-content/new-content/).
+* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
index 2a3325d397..5d3b519bc0 100644
--- a/content/en/docs/contribute/style/page-content-types.md
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines:
interested in reading next.
An example of a published tutorial topic is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
### Reference
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 55aa30d66c..44653708ec 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -22,8 +22,11 @@ discussion.
{{< note >}}
-Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
-and representing feature state.
+Kubernetes documentation uses
+[Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
+with some adjustments along with a few
+[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support
+glossary entries, tabs, and representing feature state.
{{< /note >}}
## Language
@@ -584,12 +587,8 @@ The Federation feature provides ... | The new Federation feature provides ...
{{< /table >}}
-
-
## {{% heading "whatsnext" %}}
-
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [using page templates](/docs/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 3e4f999c08..7cac1aa6b7 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs.
## {{% heading "prerequisites" %}}
Create a fork of the Kubernetes documentation repository as described in
-[Open a PR](/docs/new-content/open-a-pr/).
+[Open a PR](/docs/contribute/new-content/open-a-pr/).
@@ -160,7 +160,7 @@ submitted to ensure all examples pass the tests.
{{< /note >}}
For an example of a topic that uses this technique, see
-[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
+[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/).
## Adding images to a topic
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index c0747f3d56..7e1f8ced66 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -677,9 +677,6 @@ for more information.
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
for more information.
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index d196be938d..398f06b671 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 1227f750eb..a9db3b00eb 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -997,7 +997,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
### Matching requests: matchPolicy
API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 20b1224e59..2be833826c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation.
Kubernetes RBAC API discovery roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:basic-user
system:authenticated group
@@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation.
system:authenticated and system:unauthenticated groups
Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
+
### User-facing roles
@@ -649,12 +653,15 @@ metadata:
```
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
cluster-admin
system:masters group
@@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials
in the namespace, which would allow API access as any ServiceAccount
in the namespace (a form of privilege escalation).
+
### Core component roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:kube-scheduler
system:kube-scheduler user
@@ -733,17 +744,21 @@ The system:node role only exists for compatibility with Kubernetes clus
system:kube-proxy user
Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+
### Other component roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:auth-delegator
None
@@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho
None
Allows access to the resources required by most dynamic volume provisioners.
+
### Roles for built-in controllers {#controller-roles}
diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md
index f14393072c..b551dead19 100755
--- a/content/en/docs/reference/glossary/pod.md
+++ b/content/en/docs/reference/glossary/pod.md
@@ -2,7 +2,7 @@
title: Pod
id: pod
date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /docs/concepts/workloads/pods/
short_description: >
A Pod represents a set of running containers in your cluster.
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 25b7d46af9..c0adee3bdb 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API.
To eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
The version is set at the API level rather than at the resource or field level to:
@@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve
to pick up the `--runtime-config` changes.
{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
new file mode 100644
index 0000000000..a7be3b267f
--- /dev/null
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -0,0 +1,103 @@
+---
+title: Kubernetes API health endpoints
+reviewers:
+- logicalhan
+content_type: concept
+weight: 50
+---
+
+
+The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
+This page describes these API endpoints and explains how you can use them.
+
+
+
+## API endpoints for health
+
+The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
+The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
+The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
+For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
+Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
+A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
+
+The following examples will show how you can interact with the health API endpoints.
+
+For all endpoints you can use the `verbose` parameter to print out the checks and their status.
+This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+
+ ```shell
+ curl -k https://localhost:6443/livez?verbose
+ ```
+
+or from a remote host with authentication:
+
+ ```shell
+ kubectl get --raw='/readyz?verbose'
+ ```
+
+The output will look like this:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ healthz check passed
+
+The Kubernetes API server also supports to exclude specific checks.
+The query parameters can also be combined like in this example:
+
+ ```shell
+ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+ ```
+
+The output show that the `etcd` check is excluded:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd excluded: ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ [+]shutdown ok
+ healthz check passed
+
+## Individual health checks
+
+{{< feature-state state="alpha" >}}
+
+Each individual health check exposes an http endpoint and could can be checked individually.
+The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server.
+The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
+These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
+
+ ```shell
+ curl -k https://localhost:6443/livez/etcd
+ ```
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index c8692c8872..2b8f7b487f 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
@@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
### Addon Resources
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
For example:
@@ -94,28 +94,26 @@ For example:
memory: 200Mi
```
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
- * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
- * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
- * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+ * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+ * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+ * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
- * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+ * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
- * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
- * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+ * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+ * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
### Allowing minor node failure at startup
@@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh
with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
reason for the failure, those additional nodes may join later or the cluster may remain at a size of
`NUM_NODES - ALLOWED_NOTREADY_NODES`.
+
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index ab61c839a9..7c2622641b 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -78,7 +78,7 @@ federation support).
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
### Volume limitations
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
index a794141f2d..009be9adc8 100644
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ b/content/en/docs/setup/learning-environment/minikube.md
@@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo
The `minikube start` command can be used to start your cluster.
This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
+This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster.
{{< note >}}
If you are behind a web proxy, you need to pass this information to the `minikube start` command:
@@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
## Community
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
index 1f7d1fd81f..c440f14b31 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
@@ -9,12 +9,10 @@ content_type: concept
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-
-
## Prerequisites
@@ -112,10 +110,7 @@ e9af8293... role=node
## Support Level
-
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md
index 7cbeccf7cb..8394c28faf 100644
--- a/content/en/docs/setup/production-environment/tools/kops.md
+++ b/content/en/docs/setup/production-environment/tools/kops.md
@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
but not under `example.com`).
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
@@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
## {{% heading "whatsnext" %}}
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index aa9245ea65..82184f7784 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -8,7 +8,7 @@ weight: 30
-
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
-(CNI) based Pod network add-on so that your Pods can communicate with each other.
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
- networks: you are likely to see problems if there is any overlap.
+ networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
@@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
- control).
+ control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
- supports IPv6.
+ supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
{{< /caution >}}
@@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers.
{{< /note >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
-See the list of available
-[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
@@ -297,79 +297,6 @@ kubectl apply -f
```
You can install only one Pod network per cluster.
-Below you can find installation instructions for some popular Pod network plugins:
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
-
-Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-
-To deploy Cilium you just need to run:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
-```
-
-Once all Cilium Pods are marked as `READY`, you start using your cluster.
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-The output is similar to this:
-```
-NAME READY STATUS RESTARTS AGE
-cilium-drxkl 1/1 Running 0 18m
-```
-
-Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
-
-For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
-
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
-offering feature-rich & high-performance cloud-native networking and services.
-
-It implements k8s services and network policies in the user space (on VPP).
-
-Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
-
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
-
-For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-
-For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/).
-
-Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
-Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
-if they don't know their PodIP.
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-{{% /tab %}}
-
-{{< /tabs >}}
-
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
@@ -578,9 +505,9 @@ options.
* See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
for details about upgrading your cluster using `kubeadm`.
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
-of Pod network add-ons.
+ of Pod network add-ons.
* See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
explore other add-ons, including tools for logging, monitoring, network policy, visualization &
control of your Kubernetes cluster.
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 5584309406..e91e9f7a60 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool
If you encounter issues with setting up the HA cluster, please provide us with feedback
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
-See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
{{< caution >}}
This page does not address running your cluster on a cloud provider. In a cloud
@@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
-
-
## {{% heading "prerequisites" %}}
@@ -51,8 +49,6 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-
-
## First steps for both methods
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 334e2266f2..d860a88bdd 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -13,14 +13,12 @@ weight: 100
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/)
configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-
-
#### Caveats
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index a4d6d54cc2..696778f974 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
+- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`,
+ or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-
-
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 64ad3f4b1a..02d99d926a 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -8,7 +8,7 @@ weight: 30
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
* composable attributes
@@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* openSUSE Leap 15
* continuous integration tests
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-
-
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
@@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment:
### (2/5) Compose an inventory file
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
@@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* {{< glossary_tooltip term_id="cri-o" >}}
* Certificate generation methods
-Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
### (4/5) Deploy a Cluster
@@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
index cbfccd7a56..be75623158 100644
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ b/content/en/docs/setup/production-environment/turnkey/aws.md
@@ -48,7 +48,7 @@ export PATH=/platforms/darwin/amd64:$PATH
export PATH=/platforms/linux/amd64:$PATH
```
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
+An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
@@ -63,7 +63,8 @@ For more complete applications, please look in the [examples directory](https://
## Scaling the cluster
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
+Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
+[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
## Tearing down the cluster
@@ -80,13 +81,8 @@ cluster/kube-down.sh
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
-AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
-AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
+AWS | CoreOS | CoreOS | flannel | - | | Community
+AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
index 60c4e690d9..3ea666eb7c 100644
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ b/content/en/docs/setup/production-environment/turnkey/gce.md
@@ -72,7 +72,7 @@ cluster/kube-up.sh
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
The next few steps will show you:
@@ -85,7 +85,7 @@ The next few steps will show you:
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
manager. It lets you inspect your cluster resources, create, delete, and update
components, and much more. You will use it to look at your new cluster and bring
up example apps.
@@ -98,7 +98,7 @@ gcloud components install kubectl
{{< note >}}
The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
document to see how you can set up the latest `kubectl` on your workstation.
{{< /note >}}
@@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
kubectl get --all-namespaces services
```
-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
```shell
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
@@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3
...
```
-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
You can do this via the
```shell
@@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
### Run some examples
-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
@@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index b0c5f1596d..812d86faf7 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications
## Windows containers in Kubernetes
-To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
+To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
@@ -65,7 +65,7 @@ From an API and kubectl perspective, Windows containers behave in much the same
Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
-* [Pods](/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/docs/concepts/workloads/pods/)
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index 6a115f72cc..310127f838 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
## Supported versions
Kubernetes versions are expressed as **x.y.z**,
-where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
+where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 9288ec3064..a0c68ff682 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Create `example-ingress.yaml` from the following file:
- apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
+ apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-ingress
@@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via
Output:
```shell
- ingress.extensions/example-ingress configured
+ ingress.networking/example-ingress configured
```
## Test Your Ingress
diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
index fe90981432..1194288386 100644
--- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment:
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has two
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has two
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
+
1. Display information about the Deployment:
```shell
kubectl get deployments hello-world
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 729c7bde4f..be7cbf2673 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -19,15 +19,15 @@ PersistentVolume.
## Why change reclaim policy of a PersistentVolume
-`PersistentVolumes` can have various reclaim policies, including "Retain",
-"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
+PersistentVolumes can have various reclaim policies, including "Retain",
+"Recycle", and "Delete". For dynamically provisioned PersistentVolumes,
the default reclaim policy is "Delete". This means that a dynamically provisioned
volume is automatically deleted when a user deletes the corresponding
-`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume
+PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
contains precious data. In that case, it is more appropriate to use the "Retain"
-policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
-the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
-`Released` phase, where all of its data can be manually recovered.
+policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
+the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
+Released phase, where all of its data can be manually recovered.
## Changing the reclaim policy of a PersistentVolume
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 6fd887bd8f..f333b215a2 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
The output is:
- deployment.extensions/dns-autoscaler scaled
+ deployment.apps/dns-autoscaler scaled
Verify that the replica count is zero:
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e82c53f3a6..c3498fce61 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### Joining a Windows worker node
{{< note >}}
You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
{{< /note >}}
{{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
index b4b7afd6de..1d1461ade7 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
This example assumes the following:
1. You have an [existing Kubernetes cluster](/docs/setup/).
-2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
## Understand the default namespace
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index 1b47b14188..00dec41774 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
## {{% heading "prerequisites" %}}
* Have an [existing Kubernetes cluster](/docs/setup/).
-* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index e18b2ed87d..ed1b9657c8 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites:
You can use `kubectl drain` to safely evict all of your pods from a
node before you perform maintenance on the node (e.g. kernel upgrade,
hardware maintenance, etc.). Safe evictions allow the pod's containers
-to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
and will respect the `PodDisruptionBudgets` you have specified.
{{< note >}}
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index f5116e7691..00b9251be8 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes.
Kubernetes sends the preStop event immediately before the Container is terminated.
Kubernetes' management of the Container blocks until the preStop handler completes,
unless the Pod's grace period expires. For more details, see
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
{{< note >}}
Kubernetes only sends the preStop event when a Pod is *terminated*.
diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md
index 5189fdb882..cf31d822d6 100644
--- a/content/en/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/static-pod.md
@@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Unlike Pods that are managed by the control plane (for example, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}});
-instead, the kubelet watches each static Pod (and restarts it if it crashes).
+instead, the kubelet watches each static Pod (and restarts it if it fails).
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index f64a55bd29..aad8aac2ee 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -133,6 +133,40 @@ log audit backend using the following `kube-apiserver` flags:
- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example,
+`
+--audit-policy-file=/etc/kubernetes/audit-policy.yaml
+--audit-log-path=/var/log/audit.log
+`
+then mount the volumes:
+
+
+```
+volumeMounts:
+ - mountPath: /etc/kubernetes/audit-policy.yaml
+ name: audit
+ readOnly: true
+ - mountPath: /var/log/audit.log
+ name: audit-log
+ readOnly: false
+```
+finally the hostPath:
+
+```
+- name: audit
+ hostPath:
+ path: /etc/kubernetes/audit-policy.yaml
+ type: File
+
+- name: audit-log
+ hostPath:
+ path: /var/log/audit.log
+ type: FileOrCreate
+
+```
+
+
+
### Webhook backend
Webhook backend sends audit events to a remote API, which is assumed to be the
@@ -206,7 +240,7 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
If you're extending the Kubernetes API with the [aggregation
layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/),
-y ou can also set up audit logging for the aggregated apiserver. To do this,
+you can also set up audit logging for the aggregated apiserver. To do this,
pass the configuration options in the same format as described above to the
aggregated apiserver and set up the log ingesting pipeline to pick up audit
logs. Different apiservers can have different audit configurations and
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index a5c37541c3..edd23c35e7 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -118,7 +118,7 @@ You can view this resource with:
kubectl get endpoints ${SERVICE_NAME}
```
-Make sure that the endpoints match up with the number of containers that you expect to be a member of your service.
+Make sure that the endpoints match up with the number of pods that you expect to be members of your service.
For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different
IP addresses in the Service's endpoints.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 9793b472e0..8fb5bffd37 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
- [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and with
+ Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md
deleted file mode 100644
index 634b9d33c1..0000000000
--- a/content/en/docs/tasks/debug-application-cluster/falco.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: Auditing with Falco
----
-
-
-### Use Falco to collect audit events
-
-[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
-This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
-
-
-
-#### Install Falco
-
-Install Falco by using one of the following methods:
-
-- [Standalone Falco](https://falco.org/docs/installation)
-- [Kubernetes DaemonSet](https://falco.org/docs/installation)
-- [Falco Helm Chart](https://github.com/falcosecurity/charts/tree/master/falco)
-
-Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
-
-```yaml
-webserver:
- enabled: true
- listen_port: 8765
- k8s_audit_endpoint: /k8s_audit
- ssl_enabled: false
- ssl_certificate: /etc/falco/falco.pem
-```
-
-This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
-
-#### Configure Kubernetes Audit
-
-1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
- for the [kube-apiserver](/docs/reference/generated/kube-apiserver/) webhook audit backend.
-
- cat < /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
-
-1. Start `kube-apiserver` with the following options:
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
-
-#### Audit Rules
-
-Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml](https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml).
-If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
-
-There are three classes of rules.
-
-The first class of rules looks for suspicious or exceptional activities, such as:
-
-- Any activity by an unauthorized or anonymous user.
-- Creating a pod with an unknown or disallowed image.
-- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
-- Creating a NodePort service.
-- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
-- Attaching to or executing a command on a running pod.
-- Creating a namespace external to a set of allowed namespaces.
-- Creating a pod or service account in the kube-system or kube-public namespaces.
-- Trying to modify or delete a system ClusterRole.
-- Creating a ClusterRoleBinding to the cluster-admin role.
-- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
-- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
-
-A second class of rules tracks resources being created or destroyed, including:
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
-
-The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
-
-For further details, see [Kubernetes Audit Events](https://falco.org/docs/event-sources/kubernetes-audit) in the Falco documentation.
-
-
diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 4afbee21c8..b14777111e 100644
--- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -129,45 +129,8 @@ If RBAC is enabled on your cluster, you must update the `system:kube-scheduler`
```
kubectl edit clusterrole system:kube-scheduler
```
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- annotations:
- rbac.authorization.kubernetes.io/autoupdate: "true"
- labels:
- kubernetes.io/bootstrapping: rbac-defaults
- name: system:kube-scheduler
-rules:
-- apiGroups:
- - coordination.k8s.io
- resources:
- - leases
- verbs:
- - create
-- apiGroups:
- - coordination.k8s.io
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - leases
- verbs:
- - get
- - update
-- apiGroups:
- - ""
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - endpoints
- verbs:
- - delete
- - get
- - patch
- - update
-```
+
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
## Specify schedulers for pods
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index 7a4a94fab4..57e54e6797 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp
### Persistent Volumes
-Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
{{< note >}}
Use caution when deleting a PVC, as it may lead to data loss.
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 48a61a260d..e706c6179a 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods
```
-For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver.
+For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 7f3b046b68..6806ba0dc0 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -47,7 +47,7 @@ The Dockerfile has the following content:
```
FROM php:5-apache
-ADD index.php /var/www/html/index.php
+COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index cabf9a3c7b..7f43d34be7 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -2,5 +2,40 @@
title: "Install Tools"
description: Set up Kubernetes tools on your computer.
weight: 10
+no_list: true
---
+## kubectl
+
+The Kubernetes command-line tool, `kubectl`, allows you to run commands against
+Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
+cluster resources, and view logs.
+
+See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
+download and install `kubectl` and set it up for accessing your cluster.
+
+You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
+Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
+or for daily development work.
+
+You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
+guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
+is on getting the tool installed.
+
+Once you have Minikube working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+
+## kind
+
+Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local compute. Unlike Minikuke, kind only works with a single container runtime:
+it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
+and configured.
+
+[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
+need to do to get up and running with kind.
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 25b5cab9b5..22b960751f 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -28,7 +28,7 @@ You must use a kubectl version that is within one minor version difference of yo
1. Download the latest release with the command:
```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 9ba2de1abf..f0aa44369e 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re
## Create a Deployment
-A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
+A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 6d7e15a7c4..fb782458de 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
- A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
+ A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 8a7d60dd87..c610b6e9f4 100644
--- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
Overview of Kubernetes Services
- Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
+ Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md
index 2e8710b758..d04902ddfe 100644
--- a/content/en/docs/tutorials/services/source-ip.md
+++ b/content/en/docs/tutorials/services/source-ip.md
@@ -1,6 +1,7 @@
---
title: Using Source IP
content_type: tutorial
+mermaid: true
min-kubernetes-server-version: v1.5
---
@@ -177,7 +178,7 @@ service/nodeport exposed
```shell
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
-NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
+NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
```
If you're running on a cloud provider, you may need to open up a firewall-rule
@@ -206,18 +207,19 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th
Visually:
-```
- client
- \ ^
- \ \
- v \
- node 1 <--- node 2
- | ^ SNAT
- | | --->
- v |
- endpoint
-```
+{{< mermaid >}}
+graph LR;
+ client(client)-->node2[Node 2];
+ node2-->client;
+ node2-. SNAT .->node1[Node 1];
+ node1-. SNAT .->node2;
+ node1-->endpoint(Endpoint);
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{}}
To avoid this, Kubernetes has a feature to
[preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip).
@@ -261,17 +263,18 @@ This is what happens:
Visually:
-```
- client
- ^ / \
- / / \
- / v X
- node 1 node 2
- ^ |
- | |
- | v
- endpoint
-```
+{{< mermaid >}}
+graph TD;
+ client --> node1[Node 1];
+ client(client) --x node2[Node 2];
+ node1 --> endpoint(endpoint);
+ endpoint --> node1;
+
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{}}
@@ -324,17 +327,7 @@ deliberately failing health checks.
Visually:
-```
- client
- |
- lb VIP
- / ^
- v /
-health check ---> node 1 node 2 <--- health check
- 200 <--- ^ | ---> 500
- | V
- endpoint
-```
+
You can test this by setting the annotation:
diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
index 2974c77c94..5babc2c0b0 100644
--- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has five
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has five
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
1. Display information about the Deployment:
diff --git a/content/en/examples/admin/sched/clusterrole.yaml b/content/en/examples/admin/sched/clusterrole.yaml
new file mode 100644
index 0000000000..554b8659db
--- /dev/null
+++ b/content/en/examples/admin/sched/clusterrole.yaml
@@ -0,0 +1,37 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ annotations:
+ rbac.authorization.kubernetes.io/autoupdate: "true"
+ labels:
+ kubernetes.io/bootstrapping: rbac-defaults
+ name: system:kube-scheduler
+rules:
+ - apiGroups:
+ - coordination.k8s.io
+ resources:
+ - leases
+ verbs:
+ - create
+ - apiGroups:
+ - coordination.k8s.io
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - leases
+ verbs:
+ - get
+ - update
+ - apiGroups:
+ - ""
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - endpoints
+ verbs:
+ - delete
+ - get
+ - patch
+ - update
diff --git a/content/es/_index.html b/content/es/_index.html
index cf19b195cd..8aecd07aaf 100644
--- a/content/es/_index.html
+++ b/content/es/_index.html
@@ -4,8 +4,6 @@ abstract: "Automatización del despliegue, escalado y administración de contene
cid: home
---
-{{< deprecationwarning >}}
-
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
### Kubernetes (K8s) es una plataforma de código abierto para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores.
@@ -57,4 +55,4 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr
{{< /blocks/section >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..b607f0b82d
--- /dev/null
+++ b/content/es/docs/concepts/configuration/configmap.md
@@ -0,0 +1,253 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+
+
+{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}}
+
+{{< caution >}}
+ConfigMap no proporciona encriptación.
+Si los datos que quieres almacenar son confidenciales, utiliza un
+{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap,
+o utiliza otras herramientas externas para mantener los datos seguros.
+{{< /caution >}}
+
+
+
+
+## Motivo
+
+Utiliza un ConfigMap para crear una configuración separada del código de la aplicación.
+
+Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en
+tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real).
+Escribes el código para configurar una variable llamada `DATABASE_HOST`.
+En tu equipo configuras la variable con el valor `localhost`.
+En el cloud, la configuras con referencia a un kubernetes
+{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente
+de la base de datos en tu cluster.
+
+Esto permite tener una imagen corriendo en un cloud y
+tener el mismo código localmente para checkearlo si es necesario.
+
+## Objeto ConfigMap
+
+Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API
+que permite almacenar la configuración de otros objetos utilizados. Aunque muchos
+objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para
+almacenar items, identificados por una clave, y sus valores.
+
+El nombre del ConfigMap debe ser un
+[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
+
+## ConfigMaps y Pods
+
+Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es)
+de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en
+el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+
+Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple,
+y otras claves donde el valor tiene un formato de un fragmento de configuración.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # property-like keys; each key maps to a simple value
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+ #
+ # file-like keys
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+Hay cuatro maneras diferentes de usar un ConfigMap para configurar
+un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Argumento en la linea de comandos como entrypoint de un contenedor
+1. Variable de enorno de un contenedor
+1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación
+1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap
+
+Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar
+los datos que se van a usar.
+Para los primeros tres mecanismos, el
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información
+del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+
+Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos.
+Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede
+suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar
+cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta
+técnica también permite acceder al ConfigMap en diferentes namespaces.
+
+En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: game.example/demo-game
+ env:
+ # Define the environment variable
+ - name: PLAYER_INITIAL_LIVES # Notice that the case is different here
+ # from the key name in the ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # The ConfigMap this value comes from.
+ key: player_initial_lives # The key to fetch.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # You set volumes at the Pod level, then mount them into containers inside that Pod
+ - name: config
+ configMap:
+ # Provide the name of the ConfigMap you want to mount.
+ name: game-demo
+ # An array of keys from the ConfigMap to create as files
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+
+Un ConfigMap no diferencia entre las propiedades de una linea individual y
+un fichero con múltiples lineas y valores.
+Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores.
+
+Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor
+`demo` como `/config` creando dos ficheros,
+`/config/game.properties` y `/config/user-interface.properties`,
+aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición
+del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`.
+Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en
+un fichero con el mismo nombre que la clave, y tienes 4 ficheros.
+
+## Usando ConfigMaps
+
+Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras
+partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo,
+los ConfigMaps pueden contener información para que otros elementos del sistema utilicen
+para su configuración.
+
+{{< note >}}
+La manera más común de usar los Configmaps es para configurar
+los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+También se pueden usar por separado.
+
+Por ejemplo,
+quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}}
+u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que
+ajustan su comportamiento en base a un ConfigMap.
+{{< /note >}}
+
+### Usando ConfigMaps como ficheros en un Pod
+
+Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap.
+1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap.
+1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap.
+1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`.
+
+En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`.
+
+Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio
+bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap.
+
+#### ConfigMaps montados son actualizados automáticamente
+
+Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también.
+El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización.
+Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap.
+El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo
+todas las consultas directamente a la API.
+Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento
+que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}}
++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de
+caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar
+{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión
+(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus
+datos con las siguientes ventajas:
+
+- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones
+- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}},
+cerrando las vistas para el ConfigMap marcado como inmutable.
+
+Para usar esta característica, habilita el `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura
+el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio
+ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap.
+Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable
+recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+{{< /note >}}
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Leer sobre [Secrets](/docs/concepts/configuration/secret/).
+* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar
+ el código de la configuración.
diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..577e24dc1f
--- /dev/null
+++ b/content/es/docs/reference/glossary/configmap.md
@@ -0,0 +1,18 @@
+---
+title: Configmap
+id: configmap
+date: 2020-07-11
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+ Almacena información no sensible.
+
+aka:
+tags:
+- workload
+---
+Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}.
+
+Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables.
+
+
+
diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md
index 8d60357aea..2a88388374 100644
--- a/content/fr/docs/tasks/tools/install-kubectl.md
+++ b/content/fr/docs/tasks/tools/install-kubectl.md
@@ -121,7 +121,7 @@ kubectl version --client
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
-2. Rendrez le binaire kubectl exécutable.
+2. Rendez le binaire kubectl exécutable.
```
chmod +x ./kubectl
diff --git a/content/id/_index.html b/content/id/_index.html
index 47d7f71ced..e95d661b76 100644
--- a/content/id/_index.html
+++ b/content/id/_index.html
@@ -4,7 +4,6 @@ abstract: "Otomatisasi Kontainer deployment, scaling, dan management"
cid: home
---
-{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
@@ -60,4 +59,4 @@ Kubernetes sebagai open source memberikan kamu kebebasan untuk menggunaka
{{< blocks/kubernetes-features >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md
index ebc205d84a..33f4ada445 100644
--- a/content/id/docs/concepts/_index.md
+++ b/content/id/docs/concepts/_index.md
@@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail.
Objek mendasar Kubernetes termasuk:
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
+* [Pod](/id/docs/concepts/workloads/pods/pod-overview/)
+* [Service](/id/docs/concepts/services-networking/service/)
+* [Volume](/id/docs/concepts/storage/volumes/)
+* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/)
Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler.
Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
+* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/)
## *Control Plane* Kubernetes
@@ -95,7 +95,7 @@ dengan *node* secara langsung.
#### Metadata objek
-* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/)
+* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/)
diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md
index a0ff6b9256..6cf90cf9e6 100644
--- a/content/id/docs/concepts/architecture/controller.md
+++ b/content/id/docs/concepts/architecture/controller.md
@@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan.
Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari
Kubernetes.
-[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
+[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau
lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat
keadaan sekarang mendekati keadaan yang diinginkan.
@@ -174,6 +174,6 @@ khusus itu lakukan.
* Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane)
* Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects)
-* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
-* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
+* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/)
+* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md
index 8913c9df65..ab13cf122a 100644
--- a/content/id/docs/concepts/architecture/nodes.md
+++ b/content/id/docs/concepts/architecture/nodes.md
@@ -8,8 +8,8 @@ weight: 10
Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya.
-Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
-Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
+Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
+Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node).
@@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk
Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali.
Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan.
-Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
+Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual.
Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.
-Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
+Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod.
Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel.
@@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node.
## Manajemen
-Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
+Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat.
Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak.
Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
@@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m
Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints.
Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`.
-Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
+Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition.
Ini merupakan fitur alpha untuk versi 1.8.
@@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak
Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node.
Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node.
-Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
+Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md
index b404465d8f..ca50347492 100644
--- a/content/id/docs/concepts/cluster-administration/addons.md
+++ b/content/id/docs/concepts/cluster-administration/addons.md
@@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
* [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan.
-* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal.
## _Service Discovery_
diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md
index a605a78547..ee1f91cbeb 100644
--- a/content/id/docs/concepts/cluster-administration/certificates.md
+++ b/content/id/docs/concepts/cluster-administration/certificates.md
@@ -245,6 +245,6 @@ done.
Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan
sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan
-[di sini](/docs/tasks/tls/managing-tls-in-a-cluster).
+[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster).
diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md
index 45820e3660..9a32af1eb8 100644
--- a/content/id/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md
@@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan
Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node.
### *Load Balancer*
-Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
+Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
```yaml
apiVersion: v1
diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
index b485b5e142..b2bd349908 100644
--- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent
Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan:
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
- - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
+ - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/).
- Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**?
- Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster.
- - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai.
+ - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai.
- Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**?
- Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster.
@@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
* Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/).
-* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
+* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
## Mengamankan Klaster
-* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
+* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
-* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
+* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
* [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*.
@@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
## Layanan Tambahan Klaster
-* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
+* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
-* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
+* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md
index 7690a75a82..d59da126ad 100644
--- a/content/id/docs/concepts/cluster-administration/federation.md
+++ b/content/id/docs/concepts/cluster-administration/federation.md
@@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
-* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
+* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/)
[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
index 53203777f2..75f3b97189 100644
--- a/content/id/docs/concepts/cluster-administration/logging.md
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna
{{< /note >}}
Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
-yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
+yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md
index 81c0ba4d08..d67da9c13e 100644
--- a/content/id/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md
@@ -6,7 +6,7 @@ weight: 40
-Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/).
+Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/).
@@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`).
-Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
+Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
## Memperbarui anotasi
@@ -309,7 +309,7 @@ metadata:
...
```
-Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
+Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
## Memperbesar dan memperkecil aplikasi kamu
@@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image
kubectl edit deployment/my-nginx
```
-Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/).
+Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/).
@@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang
- [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/)
+- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/)
diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md
index 038465bcb8..6bcd78d7ef 100644
--- a/content/id/docs/concepts/cluster-administration/networking.md
+++ b/content/id/docs/concepts/cluster-administration/networking.md
@@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja.
Ada 4 masalah yang berbeda untuk diatasi:
1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh
- [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
+ [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
-3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
-4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
+3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
+4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
@@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus
### Romana
-[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
+[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
### Weave Net dari Weaveworks
diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md
index 5595414aa9..f3567233e0 100644
--- a/content/id/docs/concepts/cluster-administration/proxies.md
+++ b/content/id/docs/concepts/cluster-administration/proxies.md
@@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai proxy yang ada di dalam Kubernetes.
Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes:
-1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- dijalankan pada desktop pengguna atau di dalam sebuah Pod
- melakukan proxy dari alamat localhost ke apiserver Kubernetes
@@ -23,7 +23,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- mencari lokasi apiserver
- menambahkan header autentikasi
-1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- merupakan sebuah bastion yang ada di dalam apiserver
- menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau
@@ -33,7 +33,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- dapat digunakan untuk menghubungi Node, Pod, atau Service
- melakukan load balancing saat digunakan untuk menjangkau sebuah Service
-1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- dijalankan pada setiap Node
- melakukan proxy untuk UDP, TCP dan SCTP
diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md
index 8af1abba28..ee9e8bf2f4 100644
--- a/content/id/docs/concepts/configuration/assign-pod-node.md
+++ b/content/id/docs/concepts/configuration/assign-pod-node.md
@@ -7,7 +7,7 @@ weight: 30
-Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
+Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/)
@@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node:
Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
-Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
+Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
@@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
-Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
+Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
## nodeName
diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
index 3450bab459..600a4cc6cd 100644
--- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
@@ -10,7 +10,7 @@ feature:
-Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu
+Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu
dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan
oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya,
scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih
@@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_)
CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup
_sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan,
-dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/).
-Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah
+dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/).
+Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah
objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server.
## Request dan Limit Sumber daya dari Pod dan Container
@@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab
memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat
[Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
-Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk
+Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk
membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace,
kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya.
@@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node.
##### Sumber daya Device Plugin yang dikelola
Lihat [Device
-Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
+Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node.
##### Sumber daya lainnya
diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index 929c895821..caba991a8d 100644
--- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig,
bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster]
-(/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
@@ -103,7 +103,7 @@ kubeconfig:
abaikan mereka.
Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada
- [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+ [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`,
tanpa melakukan penggabungan.
@@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak.
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md
index 76d68658ec..67fb2061fe 100644
--- a/content/id/docs/concepts/configuration/overview.md
+++ b/content/id/docs/concepts/configuration/overview.md
@@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
-- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
+- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
- Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
+ Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
## Services
-- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
+- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
```shell
FOO_SERVICE_HOST=
@@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
-- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS.
+- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
- Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+ Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
- Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
+ Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
-- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless-
+- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
## Menggunakan label
-- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
+- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
-Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
+Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol.
@@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan
## Container Images
-Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
+Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
- `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal.
@@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`.
-- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md
index e59301bb96..13db4e32f8 100644
--- a/content/id/docs/concepts/configuration/pod-overhead.md
+++ b/content/id/docs/concepts/configuration/pod-overhead.md
@@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka
Pada Kubernetes, Overhead Pod ditentukan pada
[saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam
-[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod.
+[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod.
Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container
saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran
@@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u
## {{% heading "whatsnext" %}}
-* [RuntimeClass](/docs/concepts/containers/runtime-class/)
+* [RuntimeClass](/id/docs/concepts/containers/runtime-class/)
* [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md
index a0c6035482..7350470fa3 100644
--- a/content/id/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md
@@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan
1.11 | beta | ya
1.14 | stable | ya
-{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
+{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
{{< /warning >}}
@@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya
#### Penghentian secara sopan dari korban-korban pemindahan Pod
-Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
+Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
#### PodDisruptionBudget didukung, tapi tidak dijamin!
-Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
+Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
#### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah
diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md
index a6ca8dca88..40875648ff 100644
--- a/content/id/docs/concepts/configuration/secret.md
+++ b/content/id/docs/concepts/configuration/secret.md
@@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no
atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan
hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan.
-Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/)
+Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/)
untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_.
### Membuat Objek Secret Kamu Sendiri
@@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni
{{< note >}}
Sebuah container menggunakan Secret sebagai
-[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_
+[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_
yang di-_mount_ tidak akan menerima perubahan Secret.
{{< /note >}}
@@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P
**Memberikan spesifikasi manual dari sebuah imagePullSecret**
-Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan
@@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull
yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan
serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari
serviceAccount yang digunakan.
-Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
+Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
untuk informasi lebih detail soal proses yang dijalankan.
### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat
@@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_.
Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada
secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi
-akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources)
+akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources)
yang dibutuhkan aplikasi.
Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain
diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md
index 9a30b48f5b..723bbd1c9c 100644
--- a/content/id/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/id/docs/concepts/configuration/taint-and-toleration.md
@@ -6,7 +6,7 @@ weight: 40
-Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
+Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
@@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
-bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
@@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten
dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan.
{{< note >}}
-Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
+Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
pada skenario dimana master menjadi terpisah dari _node_ lainnya.
@@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi.
Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds
_admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
-_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
+_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
`NoExecute` untuk _taint_ tanpa `tolerationSeconds`:
* `node.kubernetes.io/unreachable`
diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md
index affb371001..6c0ba354e8 100644
--- a/content/id/docs/concepts/containers/container-environment.md
+++ b/content/id/docs/concepts/containers/container-environment.md
@@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada
*Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer:
-* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/).
+* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/).
* Informasi tentang Kontainer tersebut.
* Informasi tentang objek-objek lain di dalam klaster.
@@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
* Dapatkan pengalaman praktis soal
[memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
index a7b5164864..d45a5ad23e 100644
--- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
@@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono
untuk menghapus kontainer tersebut.
Tidak ada parameter yang diberikan pada *handler*.
-Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods).
### Implementasi *handler* untuk *hook*
@@ -113,7 +113,7 @@ Events:
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/).
+* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/).
* Pelajari bagaimana caranya
[melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md
index 7a5fa28154..8fa81801ff 100644
--- a/content/id/docs/concepts/containers/images.md
+++ b/content/id/docs/concepts/containers/images.md
@@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut:
- buang `imagePullPolicy` dan juga _tag_ untuk _image_.
- aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_.
-Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
+Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
## Membuat Image Multi-arsitektur dengan Manifest
@@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo
* `DOCKER_EMAIL`: `${some-email-address}`
Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat
-[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Menggunakan IBM Cloud Container Registry
IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu
@@ -291,7 +291,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER
Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas,
kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret.
-[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
+[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat,
perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan
hanya bekerja menggunakan satu registri privat.
@@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr
Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam
sumber daya [serviceAccount](/docs/user-guide/service-accounts).
-Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
+Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial
akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine.
diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md
index d31c760ee0..715230d14d 100644
--- a/content/id/docs/concepts/containers/overview.md
+++ b/content/id/docs/concepts/containers/overview.md
@@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda.
## Image-Image Kontainer
-[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak
+[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak
yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan
sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari
aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting.
diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md
index 31bd8a25ec..73252a03e4 100644
--- a/content/id/docs/concepts/containers/runtime-class.md
+++ b/content/id/docs/concepts/containers/runtime-class.md
@@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki.
Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya
konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari
yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass
-melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)).
+melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)).
{{< /note >}}
Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass.
@@ -91,7 +91,7 @@ spec:
Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut
untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat
-menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
+menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait.
Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan.
diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index d8be642856..3a3ece65b0 100644
--- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k
## _Custom Resource_
-Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
+Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular.
@@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men
Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya.
-Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
+Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini.
Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API.
@@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API
| Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan |
| Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. |
| Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. |
-| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
+| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
| Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. |
| Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. |
@@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku:
* Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui.
{{< note >}}
-Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
+Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
{{< /note >}}
Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku:
@@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar
Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu:
- CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun.
-- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
+- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan.
-_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
+_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD.
@@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll
Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition).
-[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
+[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
## Memilih sebuah metode untuk menambahkan _Custom Resource_
@@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan
## {{% heading "whatsnext" %}}
-* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 3bde2909ca..62f7c8d41d 100644
--- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim:
* Nama Unix socket-nya.
* Versi API Plugin Perangkat yang dipakai.
* `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti
- [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+ [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
sebagai `vendor-domain/tipe-sumber-daya`.
(Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.)
diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
index b7b07b46ff..9d80881724 100644
--- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
-*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
+*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
## Perluasan
@@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber
### Menggabungkan API Baru dengan Otomasi
-Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
+Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
### Mengubah Sumber Daya Bawaan
@@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo
* [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/)
* [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/)
* Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/)
-* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/)
+* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/)
diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md
index 269f7312a1..315ae35e3d 100644
--- a/content/id/docs/concepts/extend-kubernetes/operator.md
+++ b/content/id/docs/concepts/extend-kubernetes/operator.md
@@ -7,7 +7,7 @@ weight: 30
Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan
-[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip
Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane).
@@ -126,7 +126,7 @@ menggunakan bahasa / _runtime_ yang dapat bertindak sebagai
## {{% heading "whatsnext" %}}
-* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/)
untuk memenuhi use case kamu
* Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya:
diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
index efea4eda97..cd63a89355 100644
--- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
@@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API
merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut.
Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan.
-Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md
index 63e7b4b3af..aa2ee52152 100644
--- a/content/id/docs/concepts/overview/components.md
+++ b/content/id/docs/concepts/overview/components.md
@@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny
memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen
lainnya.
-[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
+[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services
Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini
@@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya.
### Web UI (Dasbor)
-[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
+[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun
aplikasi yang ada pada klaster itu sendiri.
@@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan.
### Cluster-level Logging
-[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
+[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan
pencarian.
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
index 9599feaf24..46066769d4 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
@@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k
Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
dalam dokumen ini:
@@ -862,8 +862,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
index e77cc9ca63..23489efb59 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
@@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
index 7df68f579d..94f1082e35 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
@@ -108,8 +108,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md
index 8a822f255d..aaa238add5 100644
--- a/content/id/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md
@@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku
## {{% heading "whatsnext" %}}
-Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/).
+Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
index 7cd81495cd..e46916ee3d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -3,14 +3,14 @@ title: Selektor Field
weight: 60
---
-Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
+Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*:
* `metadata.name=my-service`
* `metadata.namespace!=default`
* `status.phase=Pending`
-Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
+Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
`Running`:
```shell
@@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default
## Selektor berantai
-Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
+Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
(*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan
`Running` dan *field* `spec.restartPolicy` sama dengan `Always`:
diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 57eef5e9c6..aa702827b9 100644
--- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i
dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan.
Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu
-harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/).
+harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/).
Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah
yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki
menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan.
@@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md
index 5527c15b72..0d6528c41d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/names.md
+++ b/content/id/docs/concepts/overview/working-with-objects/names.md
@@ -8,7 +8,7 @@ weight: 20
Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID.
-Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/).
+Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/).
Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID.
diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
index 5eb358a17a..89ffb8ea14 100644
--- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
@@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster
*Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*.
-*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)).
+*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)).
Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*.
@@ -74,7 +74,7 @@ kubectl config view | grep namespace:
## Namespace dan DNS
-Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
+Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
## Tidak semua objek di dalam Namespace
diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md
index 2dbbd53144..991ebb44aa 100644
--- a/content/id/docs/concepts/policy/pod-security-policy.md
+++ b/content/id/docs/concepts/policy/pod-security-policy.md
@@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk
## Mengizinkan Kebijakan
-Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
+Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
-Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
+Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
### Melalui RBAC
-[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
+[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut:
@@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya
name: system:authenticated
```
-Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples).
Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh).
### Mengatasi Masalah
-- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
+- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles).
## Urutan Kebijakan
@@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode.
### Volume dan _file system_
-**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
+**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
**Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut:
diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md
index 47bfa996bb..c001ef4a40 100644
--- a/content/id/docs/concepts/policy/resource-quotas.md
+++ b/content/id/docs/concepts/policy/resource-quotas.md
@@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung:
### Resource Quota untuk sumber daya yang diperluas
Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk
-[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
+[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan
keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk
@@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi
## Resource Quota untuk penyimpanan
-Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat
+Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat
diminta pada sebuah Namespace.
Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_
@@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut.
| Nama Sumber Daya | Deskripsi |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. |
-| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
| `.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. |
-| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut:
@@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung:
| Nama Sumber Daya | Deskripsi |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. |
-| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
+| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
| `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. |
| `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. |
| `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. |
@@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k
{{< feature-state for_k8s_version="1.12" state="beta" >}}
-Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
+Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan
kolom `scopeSelector` pada spesifikasi kuota tersebut.
diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md
index f4cd477608..6f7efab3d9 100644
--- a/content/id/docs/concepts/scheduling/kube-scheduler.md
+++ b/content/id/docs/concepts/scheduling/kube-scheduler.md
@@ -94,10 +94,10 @@ penilaian oleh penjadwal:
## {{% heading "whatsnext" %}}
-* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/)
-* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_
* Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/)
-* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/)
+* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/)
diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
index 0a20d9050a..3689ecf7cb 100644
--- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
+++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -8,7 +8,7 @@ weight: 70
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
-[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
+[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
@@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim
persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
-akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md
index caff040bc5..bc271e0645 100644
--- a/content/id/docs/concepts/security/overview.md
+++ b/content/id/docs/concepts/security/overview.md
@@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi
## {{% heading "whatsnext" %}}
-* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/)
+* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/)
* Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/)
* Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/)
-* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/)
-* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/)
+* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/)
diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md
index 4bbd0bbf56..806fff3a46 100644
--- a/content/id/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/id/docs/concepts/services-networking/connect-applications-service.md
@@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
-Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
+Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
## Membuat Service
@@ -107,7 +107,7 @@ NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
```
-Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
+Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
## Mengakses Service
@@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum
* *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*)
* Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut
-* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
+* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya:
@@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
## {{% heading "whatsnext" %}}
-Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
+Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md
index 52ec19a420..efdba8d7a1 100644
--- a/content/id/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/id/docs/concepts/services-networking/dns-pod-service.md
@@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada.
### SRV _record_
SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless
-Services](/docs/concepts/services-networking/service/#headless-services).
+Services](/id/docs/concepts/services-networking/service/#headless-services).
Untuk setiap port bernama, SRV _record_ akan memiliki format
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan
diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md
index 224e7b4bbd..1782f4273e 100644
--- a/content/id/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/id/docs/concepts/services-networking/endpoint-slices.md
@@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki
referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan
_endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik.
Nama dari sebuah objek EndpointSlice haruslah berupa
-[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
+[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes
yang bernama `example`.
@@ -180,6 +180,6 @@ bersangkutan.
* [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md
index 9491f5dc1c..645f2dbf8d 100644
--- a/content/id/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/id/docs/concepts/services-networking/ingress-controllers.md
@@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang
## {{% heading "whatsnext" %}}
-* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut.
+* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut.
* [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube)
diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md
index 617581b421..1cc56c5960 100644
--- a/content/id/docs/concepts/services-networking/ingress.md
+++ b/content/id/docs/concepts/services-networking/ingress.md
@@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak
* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes.
* Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
-* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
-* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
+* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/).
+* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
## Apakah *Ingress* itu?
@@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa
```
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
-Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
+Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan
-*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau
-[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
+*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau
+[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer).
## Prasyarat
@@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se
Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta.
{{< note >}}
-Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
+Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
{{< /note >}}
GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut
@@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE.
Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus
[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis
-[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
+[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
### Sebelum kamu memulai
@@ -89,10 +89,10 @@ spec:
```
Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`.
- Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/).
+ Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/).
Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
+ [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan.
[Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress
@@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum
*loadbalancer* akan mengarahkan trafik pada *service* yang sesuai.
* Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di
- [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
+ [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
*host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait.
*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah
@@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
### *Backend Default*
Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang
-biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
+biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut
akan diarahkan pada *backend default*.
@@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga
pada kolom `address`.
{{< note >}}
-Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/)
-bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
+Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/)
+bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
{{< /note >}}
### Virtual Host berbasis Nama
@@ -291,7 +291,7 @@ spec:
### TLS
-Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret)
+Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret)
yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya
memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS.
Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda,
@@ -448,8 +448,8 @@ Ingress yang ingin diubah.
## Mekanisme *failing* pada beberapa zona *availability*
Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*.
-Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers)
-untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/)
+Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers)
+untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/)
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster.
## Pengembangan selanjutnya
@@ -463,8 +463,8 @@ soal perubahan berbagai kontroler.
Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan:
-* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
-* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer)
+* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport)
* [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md
index 25f42ddb98..fe510b846d 100644
--- a/content/id/docs/concepts/services-networking/network-policies.md
+++ b/content/id/docs/concepts/services-networking/network-policies.md
@@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy.
**_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy`
membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai
bagaimana bekerja dengan _file_ `config`, dapat dilihat di
-[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/),
serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/).
**spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu.
diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md
index ef15d1ab3d..05abffa323 100644
--- a/content/id/docs/concepts/services-networking/service-topology.md
+++ b/content/id/docs/concepts/services-networking/service-topology.md
@@ -186,5 +186,5 @@ spec:
* Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology)
-* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md
index 97626bf9ce..00bf4e6241 100644
--- a/content/id/docs/concepts/services-networking/service.md
+++ b/content/id/docs/concepts/services-networking/service.md
@@ -12,9 +12,9 @@ weight: 10
-[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
+[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut
-tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara
+tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara
khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*).
Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP
yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
@@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada.
Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi
set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_.
-Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors)
(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa
sebuah _selector_).
@@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja:
* Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_,
kamu ingin menggunakan basis datamu sendiri.
* Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada
- [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
+ [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
* Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih
berada di luar klaster Kubernetes.
@@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini.
### DNS
-Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional
+Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional
(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah
terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis
@@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_.
Server DNS Kubernetes adalah satu-satunya cara untuk mengakses
_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di
-[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/).
+[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/).
## `Service` _headless_
@@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun.
Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan
_DaemonSet_ atau melakukan spesifikasi
-[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
+[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
agar `Pod` tidak di-_assign_ ke _node_ yang sama.
-NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer).
+NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer).
Agar trafik klien berhasil mencapai _instances_ dibelakang ELB,
_security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut:
@@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS.
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)),
_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_
di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks
[protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md
index ac206dfacd..4b9fa6f35c 100644
--- a/content/id/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/id/docs/concepts/storage/dynamic-provisioning.md
@@ -8,7 +8,7 @@ weight: 40
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus
-memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
+memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/)
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
ketika diminta oleh pengguna.
@@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
memilih berbagai macam pilihan penyimpanan.
-Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/).
+Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/).
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
@@ -123,6 +123,6 @@ tidak bisa terbuat.
Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
-[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
+[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md
index f75941b86a..51163d36a9 100644
--- a/content/id/docs/concepts/storage/persistent-volumes.md
+++ b/content/id/docs/concepts/storage/persistent-volumes.md
@@ -11,7 +11,7 @@ weight: 20
-Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/).
+Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/).
@@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl
kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya
`StorageClass`.
-Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
## Siklus hidup dari sebuah volume dan klaim
@@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi:
Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut
`storageClassName` menjadi nama
-[StorageClass](/docs/concepts/storage/storage-classes/).
+[StorageClass](/id/docs/concepts/storage/storage-classes/).
Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta
kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat
dengan PVC yang tidak meminta kelas tertentu.
@@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.
### Afinitas Node
{{< note >}}
-Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local).
+Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local).
{{< /note >}}
Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_.
@@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas
### _Selector_
-Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
+Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
* `matchLabels` - volume harus memiliki label dengan nilai ini
* `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist.
@@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak
### Kelas
Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari
-[StorageClass](/docs/concepts/storage/storage-classes/)
+[StorageClass](/id/docs/concepts/storage/storage-classes/)
menggunakan atribut `storageClassName`.
Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat
terikat dengan PVC.
@@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/).
+Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/).
Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan
gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_.
diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md
index 9e0a5b1664..2897399e80 100644
--- a/content/id/docs/concepts/storage/storage-classes.md
+++ b/content/id/docs/concepts/storage/storage-classes.md
@@ -8,8 +8,8 @@ weight: 30
Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes.
Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap
-[volumes](/docs/concepts/storage/volumes/) dan
-[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu.
+[volumes](/id/docs/concepts/storage/volumes/) dan
+[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu.
@@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.
Administrator dapat memberikan spesifikasi StorageClass _default_ bagi
PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_:
-kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
untuk penjelasan lebih lanjut.
```yaml
@@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid.
### Mode Volume _Binding_
_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan
-_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning)
+_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning)
harus dilakukan.
Secara _default_, ketika mode `Immediate` yang mengindikasikan
@@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan
PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_
sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan
oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada,
-[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container),
-[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector),
+[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container),
+[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector),
[afinitas dan
-anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
-serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration).
+anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration).
Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_
dinamis:
@@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat:
* [Lokal](#lokal)
{{< feature-state state="beta" for_k8s_version="1.14" >}}
-[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung
+[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung
dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat,
meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi
untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung
@@ -634,8 +634,8 @@ parameters:
di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan.
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster
-menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan
-[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles),
+menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan
+[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles),
menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole
`system:controller:persistent-volume-binder`.
diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md
index 4a5f5d8c8c..481e74c976 100644
--- a/content/id/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md
@@ -7,7 +7,7 @@ weight: 30
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan.
+Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan.
diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md
index 0414a9d7de..fff7de9baa 100644
--- a/content/id/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,8 +7,8 @@ weight: 30
Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan,
-sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/)
-dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu.
+sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/)
+dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu.
diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md
index 39ab3d31aa..5ddfc2aaa6 100644
--- a/content/id/docs/concepts/storage/volume-snapshots.md
+++ b/content/id/docs/concepts/storage/volume-snapshots.md
@@ -7,7 +7,7 @@ weight: 20
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
+Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
@@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing
#### Dinamis
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot.
-Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi.
### Ikatan (_Binding_)
@@ -93,7 +93,7 @@ spec:
### _Class_
Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut
-`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
+`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/).
VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang
"meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat
terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_.
@@ -117,7 +117,7 @@ spec:
### _Class_
Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
menggunakan atribut `snapshotClassName`.
Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama
dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
@@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan
menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim.
-Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
+Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md
index 679de8c865..8d593f1eba 100644
--- a/content/id/docs/concepts/storage/volumes.md
+++ b/content/id/docs/concepts/storage/volumes.md
@@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk
### configMap {#configmap}
-Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
+Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod.
Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini:
@@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang
Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`.
{{< caution >}}
-Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
+Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
{{< /caution >}}
{{< note >}}
@@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r
#### Menyediakan sebuah Regional PD PersistentVolume Secara Manual
-Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce).
+Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce).
Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya:
```shell
@@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc
Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`.
-Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
+Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner).
@@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github
### persistentVolumeClaim {#persistentvolumeclaim}
-Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
+Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
-Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
+Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
### projected {#projected}
@@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github
### scaleIO {#scaleio}
-ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
+ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)).
{{< caution >}}
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
@@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya
Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`.
-Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
+Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
#### Volume CSI Sementara
diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
index 29fde331ea..ca5df2d86d 100644
--- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
@@ -6,7 +6,7 @@ weight: 80
-Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
+Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala
pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron).
@@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik
Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi.
{{< /note >}}
-Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs).
+Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs).
diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md
index baa79aa3f2..0b1c0e71e9 100644
--- a/content/id/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/id/docs/concepts/workloads/controllers/daemonset.md
@@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_
`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/),
-[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/).
+[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/).
DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib
Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus
menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)).
-Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`.
DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer
keluar/berhenti atau terjadi _crash_.
@@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m
Objek `.spec.selector` memiliki dua _field_:
-* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/).
* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih
dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan
hubungan antara _key_ dan _value_.
@@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_.
Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan
membuat Pod pada Node yang cocok dengan [selektor
-Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
-maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/).
+Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
+maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/).
Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan
membuat Pod pada semua Node.
@@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut:
* Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat
dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini
membingungkan untuk pengguna.
- * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
+ * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/)
ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan,
_controller_ DaemonSet akan membuat keputusan penjadwalan tanpa
memperhitungkan prioritas Pod dan _preemption_.
@@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet.
### _Taint_ dan _Toleration_
Meskipun Pod Daemon menghormati
-[taint dan toleration](/docs/concepts/configuration/taint-and-toleration),
+[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration),
_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai
dengan fitur yang bersangkutan.
@@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon
- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain,
contohnya _stats database_. Pod ini tidak memiliki klien.
- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi.
-- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
+- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS.
- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada
Node random. (Tidak ada cara mengakses spesifik Node)
@@ -223,7 +223,7 @@ _bootstrapping_ klaster.
### Deployment
-DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka
+DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka
sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web,
peladen penyimpanan)
diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
index 4aca03535f..5f4720646b 100644
--- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community
_Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`.
-_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
+_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`.
Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job
haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor))
dan sebuah mekanisme _restart_ yang sesuai.
-Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
+Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
### Selektor Pod
@@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak
akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian,
program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika
tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan
-[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
+[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja,
ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau
@@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan.
Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan
objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job
yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti
-[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
+[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan.
### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan
@@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif
Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan
(baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan
menerapkan mekanisme TTL yang disediakan oleh
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan
_field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut.
@@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di
Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`.
Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai dijalankan.
## Pola Job
@@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati
Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job
mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_).
-Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
+Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`.
(Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.)
@@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y
## CronJob {#cron-jobs}
-Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
+Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix.
diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md
index c0c3a83d51..57b1124208 100644
--- a/content/id/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/id/docs/concepts/workloads/controllers/replicaset.md
@@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
+_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
```shell
matchLabels:
tier: frontend
@@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_
### Menghapus ReplicaSet dan Pod-nya
-Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
+Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d.
Sebagai contoh:
@@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
```
Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru.
-Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
+Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
### Mengisolasi Pod dari ReplicaSet
@@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10
### Deployment (direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri.
Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.
@@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
### ReplicationController
-ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
+ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
index f828ff9c64..48ec718a6d 100644
--- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -13,7 +13,7 @@ weight: 20
{{< note >}}
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
{{< /note >}}
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
@@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
-Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
+Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/).
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
-`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
+`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
-Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
+Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
@@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
+_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
@@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern
### ReplicaSet
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
+[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
### Deployment (Direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
### Pod sederhana
@@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
## Informasi lanjutan
diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md
index 9d12de91dd..aa99acd6e6 100644
--- a/content/id/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/id/docs/concepts/workloads/controllers/statefulset.md
@@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada
Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau
mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan
-replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
-[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
+replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau
+[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
## Keterbatasan
@@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads
pada Kubernetes rilis sebelum versi 1.5.
* Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator.
* Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait.
-* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
+* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan
[Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default,
@@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet.
* Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan.
* StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik.
-* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
+* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
```yaml
apiVersion: v1
@@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul
serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah
`$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod
dengan nama `web-0,web-1,web-2`.
-Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain klaster.
@@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi
_field_ `serviceName` pada StatefulSet.
Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab
-untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.
Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service,
@@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
{{< note >}}
Domain klaster akan diatur menjadi `cluster.local` kecuali
-[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/).
+[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Penyimpanan Stabil
-Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
+Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap
VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume
dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_
diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
index f2c232faf2..0e1b36ccc5 100644
--- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -10,7 +10,7 @@ weight: 65
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
+[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/),
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
@@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
-[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
dilakukan secara berantai, dimana sumber daya lain yang
@@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai
## {{% heading "whatsnext" %}}
-[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md
index 1adde6c949..7a09eed3a5 100644
--- a/content/id/docs/concepts/workloads/pods/disruptions.md
+++ b/content/id/docs/concepts/workloads/pods/disruptions.md
@@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod
PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB.
-Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).))
diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
index 45154caf25..e952bdd19b 100644
--- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan
menggunakan `kubectl exec` saja.
Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan
-[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/)
+[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/)
sehingga kamu dapat melihat proses pada kontainer lain.
### Contoh
diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md
index 91807fdaf6..9cd208fbc8 100644
--- a/content/id/docs/concepts/workloads/pods/init-containers.md
+++ b/content/id/docs/concepts/workloads/pods/init-containers.md
@@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp
## Memahami Init Container
-Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
+Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
Init Container sama saja seperti Container biasa, kecuali:
@@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container:
* Mengklon sebuah _git repository_ ke dalam sebuah _volume_.
* Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.
-Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
+Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
### Menggunakan Init Container
diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
index 8dac6706a7..fdb3e7b71c 100644
--- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions]
* `PodScheduled`: Pod telah dijadwalkan masuk ke node;
* `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;
- * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
+ * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
* `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain.
* `ContainersReady`: Semua kontainer di dalam Pod telah siap.
@@ -191,7 +191,7 @@ status:
...
```
-Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
+Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan
salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/).
@@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu:
sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang
bernilai OnFailure atau Never.
-- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau
- [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
+- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/),
+ [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau
+ [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy`
yang bernilai Always.
-- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
+- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
@@ -346,7 +346,7 @@ spec:
* Dapatkan pengalaman langsung mengenai
[pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
-* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md
index 0e9593e0d1..f427358999 100644
--- a/content/id/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/id/docs/concepts/workloads/pods/pod-overview.md
@@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod*
#### Penyimpanan
-*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
+*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
## Bekerja dengan Pod
@@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika
Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi:
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*.
## Templat Pod
Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
+[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan.
@@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem
## {{% heading "whatsnext" %}}
* Pelajari lebih lanjut tentang perilaku *Pod*:
- * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
+ * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods)
+ * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md
index 3838ec56b5..e25a3a9104 100644
--- a/content/id/docs/concepts/workloads/pods/pod.md
+++ b/content/id/docs/concepts/workloads/pods/pod.md
@@ -39,7 +39,7 @@ dan bisa saling berkomunikasi melalui `localhost`. Komunikasi tersebut mengunaka
standar _inter-process communications_ (IPC) seperti SystemV semaphores
atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP
yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa
-[pengaturan khusus](/docs/concepts/policy/pod-security-policy/). Kontainer ini
+[pengaturan khusus](/id/docs/concepts/policy/pod-security-policy/). Kontainer ini
biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod.
Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama,
@@ -51,14 +51,14 @@ gabungan dari kontainer Docker yang berbagi _namespace_ dan ruang penyimpanan _f
Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal
(tidak bertahan lama). Seperti yang didiskusikan dalam
-[siklus hidup Pod](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
+[siklus hidup Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan
(bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}}
mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah
suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang
ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa
dengan nama yang sama, tapi dengan ID unik yang baru
-(baca [_replication controller_](/docs/concepts/workloads/controllers/replicationcontroller/)
+(baca [_replication controller_](/id/docs/concepts/workloads/controllers/replicationcontroller/)
untuk info lebih lanjut)
Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan,
@@ -96,7 +96,7 @@ dan Pod lain dalam jaringan yang sama.
Kontainer dalam suatu Pod melihat _hostname_ sistem sebagai sesuatu yang sama
dengan konfigurasi `name` pada Pod. Informasi lebih lanjut terdapat dibagian
-[jaringan](/docs/concepts/cluster-administration/networking/).
+[jaringan](/id/docs/concepts/cluster-administration/networking/).
Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod,
Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan
@@ -153,10 +153,10 @@ kasus mesin sedang dalam pemeliharaan.
Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka
seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya,
-[_Deployment_](/docs/concepts/workloads/controllers/deployment/). Pengontrol
+[_Deployment_](/id/docs/concepts/workloads/controllers/deployment/). Pengontrol
menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan
pengelolaan replikasi dan penluncuran.
-Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md)
+Pengontrol seperti [_StatefulSet_](/id/docs/concepts/workloads/controllers/statefulset.md)
bisa memberikan dukungan terhadap Pod yang _stateful_.
Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang
@@ -202,7 +202,7 @@ bersama dengan masa tenggang.
1. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai
"Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod
1. Jika salah satu kontainer pada Pod memiliki
- [preStop _hook_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
+ [preStop _hook_](/id/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
maka akan dipanggil di dalam kontainer. Jika `preStop` _hook_ masih berjalan
setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang
yang sedikit, 2 detik.
@@ -223,7 +223,7 @@ Secara _default_, semua penghapusan akan berjalan normal selama 30 detik. Perint
`kubectl delete` mendukung opsi `--grace-period=` yang akan
memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan
pengguna. Nilai `0` akan membuat Pod
-[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
+[dihapus paksa](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
Kamu harus memberikan opsi tambahan `--force` bersamaan dengan `--grace-period=0`
untuk melakukan penghapusan paksa.
@@ -243,7 +243,7 @@ dokumentasi untuk [penghentian Pod dari StatefulSet](/docs/tasks/run-application
## Hak istimewa untuk kontainer pada Pod
Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _privileged_), dengan menggunakan tanda
-`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/)
+`privileged` pada [konteks keamanan](/id/docs/tasks/configure-pod-container/security-context/)
pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan
kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam
kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer.
diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md
index 2fc1b8598b..9b899c4687 100644
--- a/content/id/docs/concepts/workloads/pods/podpreset.md
+++ b/content/id/docs/concepts/workloads/pods/podpreset.md
@@ -57,6 +57,6 @@ Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus mema
## {{% heading "whatsnext" %}}
- * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
+ * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/id/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md
index 8dd4c02c3a..49aa20ed6e 100644
--- a/content/id/docs/reference/access-authn-authz/rbac.md
+++ b/content/id/docs/reference/access-authn-authz/rbac.md
@@ -24,7 +24,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
## Objek API {#api-overview}
API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole,
-RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
+RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
{{< caution >}}
Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan
@@ -100,7 +100,7 @@ rules:
verbs: ["get", "watch", "list"]
```
-Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
### RoleBinding dan ClusterRoleBinding
@@ -116,7 +116,7 @@ Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu
ClusterRoleBinding.
Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan
-[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+[nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
#### Contoh RoleBinding
@@ -456,7 +456,7 @@ Di Kubernetes, modul otentikasi menyediakan informasi grup.
Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu,
selain awalan `system:` yang sudah direservasi.
-[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
+[ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
{{< note >}}
- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_.
@@ -1077,7 +1077,7 @@ In order from most secure to least secure, the approaches are:
--namespace=my-namespace
```
- Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+ Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the
"default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin
permissions to the "default" service account in the `kube-system` namespace.
diff --git a/content/id/docs/reference/kubectl/cheatsheet.md b/content/id/docs/reference/kubectl/cheatsheet.md
index 9afe999064..671ac6b77a 100644
--- a/content/id/docs/reference/kubectl/cheatsheet.md
+++ b/content/id/docs/reference/kubectl/cheatsheet.md
@@ -319,8 +319,8 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### Berbagai Tipe Sumber Daya
-Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/docs/concepts/overview/kubernetes-api/#api-groups),
-apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups),
+apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/id/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
diff --git a/content/id/docs/setup/production-environment/tools/_index.md b/content/id/docs/setup/production-environment/tools/_index.md
new file mode 100644
index 0000000000..fc98544230
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/_index.md
@@ -0,0 +1,4 @@
+---
+title: Menginstal Kubernetes dengan perkakas penyebaran
+weight: 30
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/_index.md b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
new file mode 100644
index 0000000000..f88a749c9b
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Menyiapkan klaster dengan kubeadm"
+weight: 10
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index e0db168ccd..8a345296a3 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -66,7 +66,7 @@ Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _a
### Menginstal kubeadm pada hos
-Lihat ["Menginstal kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+Lihat ["Menginstal kubeadm"](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
{{< note >}}
Jika kamu sudah menginstal kubeadm sebelumnya, jalankan `apt-get update &&
@@ -94,7 +94,7 @@ yang spesifik pada penyedia tertentu. Lihat [Menginstal _add-on_ jaringan Pod](#
3. (Opsional) Sejak versi 1.14, `kubeadm` mencoba untuk mendeteksi _runtime_ kontainer pada Linux
dengan menggunakan daftar _domain socket path_ yang umum diketahui. Untuk menggunakan _runtime_ kontainer yang berbeda atau
jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen `--cri-socket`
-pada `kubeadm init`. Lihat [Menginstal _runtime_](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+pada `kubeadm init`. Lihat [Menginstal _runtime_](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
4. (Opsional) Kecuali ditentukan sebelumnya, `kubeadm` akan menggunakan antarmuka jaringan yang diasosiasikan
dengan _default gateway_ untuk mengatur alamat _advertise_ untuk API Server pada Node _control-plane_ ini.
Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen `--apiserver-advertise-address=`
@@ -262,7 +262,7 @@ DNS klaster (CoreDNS) tidak akan menyala sebelum jaringan dipasangkan.**
`--pod-network-cidr`, atau sebagai penggantinya pada YAML _plugin_ jaringan kamu).
- Secara bawaan, `kubeadm` mengatur klastermu untuk menggunakan dan melaksanakan penggunaan
- [RBAC](/docs/reference/access-authn-authz/rbac/) (_role based access control_).
+ [RBAC](/id/docs/reference/access-authn-authz/rbac/) (_role based access control_).
Pastikan _plugin_ jaringan Pod mendukung RBAC, dan begitu juga seluruh manifes
yang kamu gunakan untuk men-_deploy_-nya.
@@ -571,14 +571,14 @@ opsinya.
untuk detail mengenai pembaruan klaster menggunakan `kubeadm`.
* Pelajari penggunaan `kubeadm` lebih lanjut pada [dokumentasi referensi kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm)
* Pelajari lebih lanjut mengenai [konsep-konsep](/docs/concepts/) Kubernetes dan [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Lihat halaman [Cluster Networking](/docs/concepts/cluster-administration/networking/) untuk daftar
+* Lihat halaman [Cluster Networking](/id/docs/concepts/cluster-administration/networking/) untuk daftar
_add-on_ jaringan Pod yang lebih banyak.
-* Lihat [daftar _add-on_](/docs/concepts/cluster-administration/addons/) untuk
+* Lihat [daftar _add-on_](/id/docs/concepts/cluster-administration/addons/) untuk
mengeksplor _add-on_ lainnya, termasuk perkakas untuk _logging_, _monitoring_, _network policy_, visualisasi &
pengendalian klaster Kubernetes.
* Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari
aplikasi-aplikasi yang berjalan pada Pod.
- Lihat [Arsitektur Logging](/docs/concepts/cluster-administration/logging/) untuk
+ Lihat [Arsitektur Logging](/id/docs/concepts/cluster-administration/logging/) untuk
gambaran umum tentang hal-hal yang terlibat.
### Umpan balik
@@ -602,7 +602,7 @@ Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v{{< skew latestVers
Sumber daya ini menyediakan informasi lebih lanjut mengenai _version skew_ yang didukung antara kubelet dan _control plane_, serta komponen Kubernetes lainnya:
* [Kebijakan versi and version-skew Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Panduan instalasi](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
+* [Panduan instalasi](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
## Keterbatasan
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
new file mode 100644
index 0000000000..afe6d1e6b8
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -0,0 +1,364 @@
+---
+title: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm
+content_type: task
+weight: 60
+---
+
+
+
+Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm:
+
+- Dengan Node _control plane_ yang bertumpuk (_stacked_). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node _control plane_ diletakkan pada tempat yang sama (_co-located_).
+- Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node _control plane_ dan anggota etcd berada pada tempat yang berbeda.
+
+Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan _environment_-mu. [Topik perbandingan berikut](/id/docs/setup/production-environment/tools/kubeadm/ha-topology/) menguraikan kelebihan dan kekurangan dari masing-masing pendekatan.
+
+Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik
+pada [pelacak isu](https://github.com/kubernetes/kubeadm/issues/new) kubeadm.
+
+Lihat juga [dokumentasi pembaruan](/id/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+
+{{< caution >}}
+Laman ini tidak menunjukkan cara untuk menjalankan klastermu pada penyedia layanan cloud. Pada _environment_ cloud, kedua pendekatan yang didokumentasikan di sini tidak akan bekerja untuk objek Service dengan tipe LoadBalancer maupun PersistentVolume dinamis.
+{{< /caution >}}
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut:
+
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk
+ Node _control plane_
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk Node _worker_
+- Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi)
+- Hak akses sudo pada seluruh mesin
+- Akses SSH dari satu perangkat ke seluruh Node pada sistem
+- Perkakas `kubeadm` dan `kubelet` diinstal pada seluruh mesin. Perkakas `kubectl` bersifat opsional.
+
+Untuk klaster etcd eksternal saja, kamu juga membutuhkan:
+
+- Tiga mesin tambahan untuk anggota-anggota etcd
+
+
+
+
+
+## Langkah pertama untuk kedua metode
+
+### Membuat _load balancer_ untuk kube-apiserver
+
+{{< note >}}
+Akan ada banyak konfigurasi untuk _load balancer_. Contoh berikut ini hanyalah salah satu
+opsi. Kebutuhan klastermu mungkin membutuhkan konfigurasi berbeda.
+{{< /note >}}
+
+1. Buat sebuah _load balancer_ kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS.
+
+ - Pada _environment_ cloud kamu harus meletakkan Node _control plane_ di belakang _load balancer_ yang meneruskan TCP. _Load balancer_ ini mendistribusikan trafik ke seluruh Node _control plane_ pada daftar tujuan. _Health check_ untuk
+ apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver
+ (nilai semula `:6443`).
+
+ - Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada _environment_ cloud.
+
+ - _Load balancer_ harus dapat berkomunikasi dengan seluruh Node _control plane_
+ pada porta yang digunakan apiserver. _Load balancer_ tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya.
+
+ - Pastikan alamat _load balancer_ sesuai
+ dengan alamat `ControlPlaneEndpoint` pada kubeadm.
+
+ - Baca panduan [Opsi untuk _Software Load Balancing_](https://github.com/kubernetes/kubeadm/blob/master/id/docs/ha-considerations.md#options-for-software-load-balancing)
+ untuk detail lebih lanjut.
+
+2. Tambahkan Node _control plane_ pertama pada _load balancer_ dan lakukan pengujian koneksi:
+
+ ```sh
+ nc -v LOAD_BALANCER_IP PORT
+ ```
+
+ - Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum
+ berjalan. Namun jika mendapat _timeout_, berarti _load balancer_ tidak dapat berkomunikasi
+ dengan Node _control plane_. Jika terjadi _timeout_, lakukan pengaturan ulang pada _load balancer_ agar dapat berkomunikasi dengan Node _control plane_.
+
+3. Tambahkan Node _control plane_ lainnya pada grup tujuan _load balancer_.
+
+## Node _control plane_ dan etcd bertumpuk (_stacked_)
+
+### Langkah-langkah untuk Node _control plane_ pertama
+
+1. Inisialisasi _control plane_:
+
+ ```sh
+ sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
+ ```
+
+ - Kamu bisa menggunakan opsi `--kubernetes-version` untuk mengatur versi Kubernetes yang akan digunakan.
+ Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama.
+
+ - Opsi `--control-plane-endpoint` harus diatur menuju alamat atau DNS dan porta dari _load balancer_.
+
+ - Opsi `--upload-certs` digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh
+ Node _control plane_ pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke
+ seluruh Node _control plane_ sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian [Distribusi sertifikat manual](#distribusi-sertifikat-manual) di bawah.
+
+ {{< note >}}
+ Opsi `--config` dan `--certificate-key` pada `kubeadm init` tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan
+ [konfigurasi kubeadm](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
+ kamu harus menambahkan _field_ `certificateKey` pada lokasi pengaturan yang sesuai
+ (berada di bawah `InitConfiguration` dan `JoinConfiguration: controlPlane`).
+ {{< /note >}}
+
+ {{< note >}}
+ Beberapa _plugin_ jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak.
+ Lihat [dokumentasi jaringan CNI](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod).
+ Untuk menambahkan CIDR Pod, tambahkan opsi `--pod-network-cidr`, atau jika kamu menggunakan berkas konfigurasi kubeadm
+ pasang _field_ `podSubnet` di bawah objek `networking` dari `ClusterConfiguration`.
+ {{< /note >}}
+
+ - Keluaran yang dihasilkan terlihat seperti berikut ini:
+
+ ```sh
+ ...
+ You can now join any number of control-plane node by running the following command on each as a root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+
+ Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+ As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+
+ Then you can join any number of worker nodes by running the following on each as root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+ ```
+
+ - Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node _control plane_ dan _worker_ ke klaster.
+ - Ketika opsi `--upload-certs` digunakan dengan `kubeadm init`, sertifikat dari _control plane_ utama
+ akan dienkripsi dan diunggah ke Secret `kubeadm-certs`.
+ - Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node _control plane_
+ yang sudah tergabung pada klaster:
+
+ ```sh
+ sudo kubeadm init phase upload-certs --upload-certs
+ ```
+
+ - Kamu juga dapat menentukan `--certificate-key` _custom_ pada saat `init` yang nanti dapat digunakan pada saat `join`.
+ Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut:
+
+ ```sh
+ kubeadm alpha certs certificate-key
+ ```
+
+ {{< note >}}
+ Secret `kubeadm-certs` dan kunci dekripsi akan kadaluarsa setelah dua jam.
+ {{< /note >}}
+
+ {{< caution >}}
+ Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya!
+ {{< /caution >}}
+
+2. Pasang _plugin_ CNI pilihanmu:
+ [Ikuti petunjuk berikut](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod)
+ untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan.
+
+ Pada contoh berikut kami menggunakan Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+3. Tulis perintah berikut dan saksikan Pod komponen-komponen _control plane_ mulai dinyalakan:
+
+ ```sh
+ kubectl get pod -n kube-system -w
+ ```
+
+### Langkah-langkah selanjutnya untuk Node _control plane_
+
+{{< note >}}
+Sejak kubeadm versi 1.15 kamu dapat menggabungkan beberapa Node _control plane_ secara bersamaan.
+Pada versi sebelumnya, kamu harus menggabungkan Node _control plane_ baru secara berurutan, setelah
+Node pertama selesai diinisialisasi.
+{{< /note >}}
+
+Untuk setiap Node _control plane_ kamu harus:
+
+1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran `kubeadm init` pada Node pertama.
+ Perintah tersebut terlihat seperti ini:
+
+ ```sh
+ sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+ ```
+
+ - Opsi `--control-plane` menunjukkan `kubeadm join` untuk membuat _control plane_ baru.
+ - Opsi `--certificate-key ...` akan membuat sertifikat _control plane_ diunduh
+ dari Secret `kubeadm-certs` pada klaster dan didekripsi menggunakan kunci yang diberikan.
+
+## Node etcd eksternal
+
+Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk
+dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd
+pada berkas konfigurasi kubeadm.
+
+### Memasang klaster etcd
+
+1. Ikuti [petunjuk berikut](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk membangun klaster etcd.
+
+2. Lakukan pengaturan SSH seperti yang dijelaskan [di sini](#distribusi-sertifikat-manual).
+
+3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node _control plane_ pertama:
+
+ ```sh
+ export CONTROL_PLANE="ubuntu@10.0.0.7"
+ scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
+ ```
+
+ - Ganti nilai `CONTROL_PLANE` dengan `user@host` dari mesin _control plane_ pertama.
+
+### Mengatur Node _control plane_ pertama
+
+1. Buat sebuah berkas bernama `kubeadm-config.yaml` dengan konten sebagai berikut:
+
+ apiVersion: kubeadm.k8s.io/v1beta2
+ kind: ClusterConfiguration
+ kubernetesVersion: stable
+ controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+ etcd:
+ external:
+ endpoints:
+ - https://ETCD_0_IP:2379
+ - https://ETCD_1_IP:2379
+ - https://ETCD_2_IP:2379
+ caFile: /etc/kubernetes/pki/etcd/ca.crt
+ certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+ keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+
+ {{< note >}}
+ Perbedaan antara etcd bertumpuk dan etcd eksternal yaitu etcd eksternal membutuhkan
+ sebuah berkas konfigurasi dengan _endpoint_ etcd di bawah objek `external`untuk `etcd`.
+ Pada kasus ini topologi etcd bertumpuk dikelola secara otomatis.
+ {{< /note >}}
+
+ - Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu:
+
+ - `LOAD_BALANCER_DNS`
+ - `LOAD_BALANCER_PORT`
+ - `ETCD_0_IP`
+ - `ETCD_1_IP`
+ - `ETCD_2_IP`
+
+Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk:
+
+1. Jalankan `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` pada Node ini.
+
+2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti.
+
+3. Pasang _plugin_ CNI pilihanmu. Contoh berikut ini untuk Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+### Langkah selanjutnya untuk Node _control plane_ lainnya
+
+Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk:
+
+- Pastikan Node _control plane_ pertama sudah diinisialisasi dengan sempurna.
+- Gabungkan setiap Node _control plane_ dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk
+menggabungkan Node _control plane_ satu persatu.
+- Jangan lupakan bahwa kunci dekripsi dari `--certificate-key` akan kadaluarsa setelah dua jam, pada pengaturan semula.
+
+## Tugas-tugas umum setelah menyiapkan _control plane_
+
+### Menginstal _worker_
+
+Node _worker_ bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya
+dari keluaran perintah `kubeadm init`:
+
+```sh
+sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+```
+
+## Distribusi sertifikat manual
+
+Jika kamu memilih untuk tidak menggunakan `kubeadm init` dengan opsi `--upload-certs` berarti kamu harus
+menyalin sertifikat dari Node _control plane_ utama secara manual ke
+Node _control plane_ yang akan bergabung.
+
+Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan `ssh` dan `scp`:
+
+SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin.
+
+1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada
+ sistem:
+
+ ```
+ eval $(ssh-agent)
+ ```
+
+2. Tambahkan identitas SSH milikmu ke dalam sesi:
+
+ ```
+ ssh-add ~/.ssh/path_to_private_key
+ ```
+
+3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik.
+
+ - Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi `-A`:
+
+ ```
+ ssh -A 10.0.0.7
+ ```
+
+ - Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan _environment_ yang ada sehingga penerusan SSH
+ dapat bekerja dengan baik:
+
+ ```
+ sudo -E -s
+ ```
+
+4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node _control plane_ pertama setelah
+ menjalankan `kubeadm init`. Skrip ini akan menyalin sertifikat dari Node _control plane_ pertama ke Node
+ _control plane_ lainnya:
+
+ Pada contoh berikut, ganti `CONTROL_PLANE_IPS` dengan alamat IP dari
+ Node _control plane_ lainnya.
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
+ for host in ${CONTROL_PLANE_IPS}; do
+ scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
+ done
+ ```
+
+ {{< caution >}}
+ Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya
+ dengan SANs yang dibutuhkan untuk Node _control plane_ yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja,
+ pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan.
+ {{< /caution >}}
+
+5. Lalu, pada setiap Node _control plane_ yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan `kubeadm join`.
+ Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori _home_ ke `/etc/kubernetes/pki`:
+
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ mkdir -p /etc/kubernetes/pki/etcd
+ mv /home/${USER}/ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/sa.pub /etc/kubernetes/pki/
+ mv /home/${USER}/sa.key /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
+ ```
+
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index c81e9f41ec..adcf73db77 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -11,7 +11,7 @@ card:
Laman ini menunjukkan cara untuk menginstal `kubeadm`.
-Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
@@ -132,14 +132,14 @@ Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berh
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{% tab name="sistem operasi lainnya" %}}
Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container.
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{< /tabs >}}
@@ -174,7 +174,7 @@ Hal ini karena kubeadm dan Kubernetes membutuhkan
Untuk informasi lebih lanjut mengenai _version skew_, lihat:
* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
+* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian atau HypriotOS" %}}
@@ -304,4 +304,4 @@ Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyel
## {{% heading "whatsnext" %}}
-* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
+* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md
index 148f402402..6a575ad8f1 100644
--- a/content/id/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md
@@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda
Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`,
yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver.
-Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/).
+Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/).
Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut,
di `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes:
- dapat digunakan untuk menjangkau Node, Pod, atau Service
- melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service
-1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- berjalan di setiap Node
- memproksi UDP dan TCP
diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index b2b80aacba..8775823304 100644
--- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -320,7 +320,7 @@ contexts:
```
Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat
-[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
## Jelajahi direktori $HOME/.kube
@@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 1c6226b1be..d6d04df2ad 100644
--- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -19,7 +19,7 @@ _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigura
Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan
servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
-silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
+silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/)
@@ -35,7 +35,7 @@ silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
## Berkas konfigurasi
Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
-[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu:
```yaml
type: LoadBalancer
diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..f2140e5276
--- /dev/null
+++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,129 @@
+---
+title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster
+content_type: task
+weight: 100
+---
+
+
+
+Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container
+untuk Pod yang berjalan dalam sebuah klaster.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang
+berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar
+Container untuk masing-masing Pod.
+
+## Membuat daftar semua _image_ Container pada semua Namespace
+
+- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces`
+- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container
+ dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_
+ `image` dari keluaran json yang dihasilkan.
+ - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/)
+ untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`.
+- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq`
+ - Gunakan `tr` untuk mengganti spasi dengan garis baru
+ - Gunakan `sort` untuk menyortir hasil
+ - Gunakan `uniq` untuk mengumpulkan jumlah _image_
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image`
+dari semua poin yang dikembalikan.
+
+Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_
+di dalam Pod. Hal ini memastikan _field_ yang diambil benar
+bahkan ketika nama _field_ tersebut diulangi,
+misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+`Jsonpath` dapat diartikan sebagai berikut:
+
+- `.items[*]`: untuk setiap nilai yang dihasilkan
+- `.spec`: untuk mendapatkan spesifikasi
+- `.containers[*]`: untuk setiap Container
+- `.image`: untuk mendapatkan _image_
+
+{{< note >}}
+Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`,
+bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod
+sebagai keluarannya, bukan daftar dari semua Pod.
+
+{{< /note >}}
+
+## Membuat daftar _image_ Container berdasarkan Pod
+
+Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk
+melakukan iterasi untuk setiap elemen secara individual.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Membuat daftar _image_ yang difilter berdasarkan label dari Pod
+
+Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter
+dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod
+
+Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter
+dibawah ini hanya menyaring Pod pada Namespace `kube-system`.
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
+
+Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/)
+untuk memformat keluaran seperti berikut:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Referensi
+
+* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/).
+* Referensi panduan [Go template](https://golang.org/pkg/text/template/).
+
+
+
+
diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
index a83605db40..99d23c823d 100644
--- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai.
_Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
-- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
+- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan.
-- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
+- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
- **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif.
- Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
+ Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
-- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal.
@@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan:
-- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
+- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
-- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
+- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
Contoh:
@@ -107,9 +107,9 @@ track=stable
Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih.
-- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/).
+- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/).
- Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
+ Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih.
@@ -123,7 +123,7 @@ track=stable
### Menggungah berkas YAML atau JSON
-Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/).
+Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/).
Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard.
diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md
new file mode 100644
index 0000000000..0b2ebea7fe
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md
@@ -0,0 +1,177 @@
+---
+title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability)
+content_type: task
+---
+
+
+
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
+
+Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE).
+Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Memulai klaster yang kompatibel dengan HA
+
+Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`:
+
+* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server.
+Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan.
+
+* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru.
+Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd.
+Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat.
+
+Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat.
+Atur tanda berikut:
+
+* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan.
+
+Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b:
+
+```shell
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+```
+
+Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_;
+Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya.
+
+
+## Menambahkan replika _control plane_ yang baru
+
+Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana.
+Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini:
+
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan.
+Region ini harus sama dengan region dari zona replika yang lain.
+
+Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`,
+karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA.
+
+Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA:
+
+```shell
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Menghapus replika _control plane_
+
+Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut:
+
+* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus.
+
+* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus.
+Jika kosong: replika mana saja dari zona yang diberikan akan dihapus.
+
+Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+```
+
+## Mengatasi replika _control plane_ yang gagal
+
+Jika salah satu replika _control plane_ di klaster HA kamu gagal,
+praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama.
+Berikut ini contoh perintah yang menunjukkan proses tersebut:
+
+1. Menghapus replika yang gagal:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
+
+2. Menambahkan replika baru untuk menggantikan replika yang lama
+
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA
+
+* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula.
+Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain
+(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail).
+
+* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten.
+Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas.
+Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal.
+
+* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru.
+Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya.
+Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang).
+
+
+
+
+
+## Catatan implementasi
+
+
+
+### Ikhtisar
+
+Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut:
+
+* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus;
+
+* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia;
+
+* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster;
+
+* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi.
+
+Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka.
+
+
+### Penyeimbang Beban
+
+Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat
+dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban.
+Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada.
+Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan.
+
+
+### Service _control plane_ & kubelet
+
+Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes,
+sistem akan mengarahkan semua lalu lintas ke IP eksternal:
+
+* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal.
+
+* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_.
+
+Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_.
+
+
+### Sertifikat _control plane_
+
+Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika.
+Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika;
+Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS.
+
+### Pengklasteran etcd
+
+Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster).
+Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL.
+
+## Bacaan tambahan
+
+[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
+
+
diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md
new file mode 100644
index 0000000000..409e42dd70
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/namespaces.md
@@ -0,0 +1,302 @@
+---
+title: Membagi sebuah Klaster dengan Namespace
+content_type: task
+---
+
+
+Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu.
+
+
+## {{% heading "prerequisites" %}}
+
+* Memiliki [Klaster Kubernetes](/id/docs/setup/).
+* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes.
+
+
+
+
+## Melihat Namespace
+
+1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan:
+
+```shell
+kubectl get namespaces
+```
+```
+NAME STATUS AGE
+default Active 11d
+kube-system Active 11d
+kube-public Active 11d
+```
+
+Kubernetes mulai dengan tiga Namespace pertama:
+
+ * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain
+ * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes
+ * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan.
+
+Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan:
+
+```shell
+kubectl get namespaces
+```
+
+Atau kamu bisa mendapatkan informasi detail menggunakan:
+
+```shell
+kubectl describe namespaces
+```
+```
+Name: default
+Labels:
+Annotations:
+Status: Active
+
+No resource quota.
+
+Resource Limits
+ Type Resource Min Max Default
+ ---- -------- --- --- ---
+ Container cpu - - 100m
+```
+
+Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya.
+
+Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace.
+
+Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace.
+
+Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
+
+Sebuah Namespace dapat berada dalam salah satu dari dua buah fase:
+
+ * `Active` Namespace sedang digunakan
+ * `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru
+
+Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut.
+
+## Membuat sebuah Namespace baru
+
+{{< note >}}
+ Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes.
+{{< /note >}}
+
+1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini:
+
+ ```yaml
+ apiVersion: v1
+ kind: Namespace
+ metadata:
+ name:
+ ```
+ Then run:
+
+ ```
+ kubectl create -f ./my-namespace.yaml
+ ```
+
+2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini:
+
+ ```
+ kubectl create namespace
+ ```
+
+Nama Namespace kamu harus merupakan
+[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid.
+
+Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya.
+
+Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace.
+
+## Menghapus Namespace
+
+Hapus Namespace dengan
+
+```shell
+kubectl delete namespaces
+
diff --git a/content/en/case-studies/northwestern-mutual/index.html b/content/en/case-studies/northwestern-mutual/index.html
index dac0ef0d66..47b4bbc7be 100644
--- a/content/en/case-studies/northwestern-mutual/index.html
+++ b/content/en/case-studies/northwestern-mutual/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
css: /css/style_case_studies.css
---
-
+
CASE STUDY:
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.
-
+
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html
index 6a930f945c..79ac9bf3a8 100644
--- a/content/en/case-studies/ocado/index.html
+++ b/content/en/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
+
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with
+
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html
index 040f704efa..1b95ec5f35 100644
--- a/content/en/case-studies/openAI/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html
index ddb567afb3..78f70228e5 100644
--- a/content/en/case-studies/pearson/index.html
+++ b/content/en/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."
-
+
-
+
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html
index 637f891b3e..8d032c7a8b 100644
--- a/content/en/case-studies/pingcap/index.html
+++ b/content/en/case-studies/pingcap/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
PingCAP Bets on Cloud Native for Its TiDB Database Platform
@@ -52,7 +52,7 @@ featured: false
Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-
+
-
+
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html
index 0aa2381aa1..e4be7031bb 100644
--- a/content/en/case-studies/pinterest/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html
index 03bbc51173..2f0beda5ae 100644
--- a/content/en/case-studies/prowise/index.html
+++ b/content/en/case-studies/prowise/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion
@@ -50,7 +50,7 @@ featured: false
The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
+
-
+
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html
index 62501c4f5b..2863ceac75 100644
--- a/content/en/case-studies/ricardo-ch/index.html
+++ b/content/en/case-studies/ricardo-ch/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
@@ -48,7 +48,7 @@ featured: false
To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
+
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH
diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html
index 4a99d28fb3..86ebe15f91 100644
--- a/content/en/case-studies/slamtec/index.html
+++ b/content/en/case-studies/slamtec/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-
+
-
+
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html
index a11527c2d9..349ed8c2de 100644
--- a/content/en/case-studies/slingtv/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html
index 64708a20f8..becf486413 100644
--- a/content/en/case-studies/sos/index.html
+++ b/content/en/case-studies/sos/index.html
@@ -8,7 +8,7 @@ logo: sos_featured_logo.png
---
-
+
CASE STUDY:
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
+
-
+
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html
index 85e7fc1e86..63243b08f6 100644
--- a/content/en/case-studies/spotify/index.html
+++ b/content/en/case-studies/spotify/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
-
+
-
+
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html
index d2b2a18c92..27340835f4 100644
--- a/content/en/case-studies/squarespace/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html
index 0a35de2b1a..ad990356ff 100644
--- a/content/en/case-studies/thredup/index.html
+++ b/content/en/case-studies/thredup/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -49,7 +49,7 @@ featured: false
"We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-
+
-
+
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html
index 4ca7aa1bbc..c2ac2a2a72 100644
--- a/content/en/case-studies/vsco/index.html
+++ b/content/en/case-studies/vsco/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
@@ -48,7 +48,7 @@ featured: false
-
+
-
+
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html
index aa41b7cb44..fbb86bdd24 100644
--- a/content/en/case-studies/woorank/index.html
+++ b/content/en/case-studies/woorank/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with
12 Engineers—At 30% Less Cost
@@ -50,7 +50,7 @@ featured: false
-
+
-
+
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html
index 95f323d5ae..1c09503bfb 100644
--- a/content/en/case-studies/workiva/index.html
+++ b/content/en/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
-
+
-
+
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
-
+
@@ -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
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html
index 498dc0ec73..c07443249a 100644
--- a/content/en/case-studies/ygrene/index.html
+++ b/content/en/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
-
+
-
+
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
index 39af4fb779..c3b51f3acf 100644
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -64,7 +64,7 @@ Before choosing a guide, here are some considerations:
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
### Securing the kubelet
- * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
+ * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index 26fc1194df..5cdd070e0f 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -303,6 +303,9 @@ to get a mapping of UIDs to names for both FlowSchemas and
PriorityLevelConfigurations.
## Observability
+
+### Metrics
+
When you enable the API Priority and Fairness feature, the kube-apiserver
exports additional metrics. Monitoring these can help you determine whether your
configuration is inappropriately throttling important traffic, or find
@@ -365,9 +368,65 @@ poorly-behaved workloads that may be harming system health.
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
+### Debug endpoints
+When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports.
+- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
+ workload-low, 0, true, false, 0, 0,
+ global-default, 0, true, false, 0, 0,
+ exempt, , , , , ,
+ catch-all, 0, true, false, 0, 0,
+ system, 0, true, false, 0, 0,
+ leader-election, 0, true, false, 0, 0,
+ workload-high, 0, true, false, 0, 0,
+ ```
+- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_queues
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart,
+ workload-high, 0, 0, 0, 0.0000,
+ workload-high, 1, 0, 0, 0.0000,
+ workload-high, 2, 0, 0, 0.0000,
+ ...
+ leader-election, 14, 0, 0, 0.0000,
+ leader-election, 15, 0, 0, 0.0000,
+ ```
+
+- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_requests
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime,
+ exempt, , , , , ,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
+ ```
+
+ In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation.
+
+ You can get a more detailed listing with a command like this:
+ ```shell
+ kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ ```
+
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index b052dd3a15..d0485a4342 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
kubectl scale deployment/my-nginx --replicas=1
```
```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
```
Now you only have one pod managed by the deployment.
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 29044be250..6779ee984a 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -12,7 +12,7 @@ understand exactly how it is expected to work. There are 4 distinct networking
problems to address:
1. Highly-coupled container-to-container communications: this is solved by
- [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications.
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications.
2. Pod-to-Pod communications: this is the primary focus of this document.
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 89a361a350..f40c99fbc4 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -224,7 +224,7 @@ data has the following advantages:
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
closing watches for config maps marked as immutable.
-To use this feature, enable the `ImmutableEmphemeralVolumes`
+To use this feature, enable the `ImmutableEphemeralVolumes`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
your Secret or ConfigMap `immutable` field to `true`. For example:
```yaml
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index db78a8304e..f791510b39 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -132,11 +132,9 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
+ - name: app
+ image: images.my-company.example/app:v4
env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
resources:
requests:
memory: "64Mi"
@@ -144,8 +142,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -330,18 +328,15 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
- env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
+ - name: app
+ image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 7eae77ac46..01e1f64d19 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -217,7 +217,7 @@ makes Pod P eligible to preempt Pods on another Node.
#### Graceful termination of preemption victims
When Pods are preempted, the victims get their
-[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
They have that much time to finish their work and exit. If they don't, they are
killed. This graceful termination period creates a time gap between the point
that the scheduler preempts Pods and the time when the pending Pod (P) can be
@@ -230,7 +230,7 @@ priority Pods to zero or a small number.
#### PodDisruptionBudget is supported, but not guaranteed
-A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/)
+A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
allows application owners to limit the number of Pods of a replicated application
that are down simultaneously from voluntary disruptions. Kubernetes supports
PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index 386e4d00bb..c8e93e93db 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
### Hook handler implementations
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index a01e8d84f9..415d920b40 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -129,7 +129,7 @@ example, run these on your desktop/laptop:
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
-For production clusers, use a configuration management tool so that you can apply this
+For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
deleted file mode 100644
index 7f81439c41..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Poseidon-Firmament Scheduler
-content_type: concept
-weight: 80
----
-
-
-
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-
-
-
-
-
-
-## Introduction
-
-Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions.
-
-Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements.
-
-Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers.
-
-Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages:
-
-- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale.
- The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs).
-- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads.
-- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run.
-- The Poseidon-Firmament scheduler supports scheduling complex rule constraints.
-
-## How the Poseidon-Firmament scheduler works
-
-Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-...
-spec:
- schedulerName: poseidon
-...
-```
-
-## Batch scheduling
-
-As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs.
-
-Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most:
-
-1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous.
-2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs).
-
-## Feature state
-
-Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases.
-
-{{< caution >}}
-Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail.
-{{< /caution >}}
-
-## Feature comparison {#feature-comparison-matrix}
-
-{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}}
-|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes|
-|--- |--- |--- |--- |
-|Node Affinity/Anti-Affinity|Y|Y||
-|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.|
-|Taints & Tolerations|Y|Y||
-|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.|
-|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.|
-|Colocation Interference Avoidance|N|N||
-|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.|
-|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.|
-|Gang Scheduling|N|Y||
-|Support for Pre-bound Persistence Volume Scheduling|Y|Y||
-|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N||
-|High Availability|Y|N||
-|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.|
-|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.|
-|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y||
-{{< /table >}}
-
-## Installation
-
-The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster.
-
-## Performance comparison
-
-{{< note >}}
- Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler.
-{{< /note >}}
-
-Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks:
-
-1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed.
-2. There is limited opportunities for amortizing work across pods because they are considered for placement individually.
-
-These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-
-
-## {{% heading "whatsnext" %}}
-
-* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
-* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
-* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
-* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index b3b6960358..42d12425b7 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -25,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-
-
## API changes
@@ -87,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Versioning is done at the API level rather than at the resource or field level to ensure that the
API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -157,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 1f4f4e7509..ab447cdcd6 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 0f2965a7a3..9829692126 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup
Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 4d3a9255d4..d7fc53a4d0 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -235,7 +235,7 @@ IngressClass resource will ensure that new Ingresses without an
If you have more than one IngressClass marked as the default for your cluster,
the admission controller prevents creating new Ingress objects that don't have
an `ingressClassName` specified. You can resolve this by ensuring that at most 1
-IngressClasess are marked as default in your cluster.
+IngressClasses are marked as default in your cluster.
{{< /caution >}}
## Types of Ingress
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 79d260d52a..9819334ce8 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -1356,7 +1356,7 @@ persistent volume:
of a volume. This map must correspond to the map returned in the
`volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as
defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
- The map is passed to the CSI driver via the `volume_attributes` field in the
+ The map is passed to the CSI driver via the `volume_context` field in the
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
`NodePublishVolumeRequest`.
- `controllerPublishSecretRef`: A reference to the secret object containing
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index 7f1b5c4630..c3d8cf36d8 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev
The `.spec.template` is one of the required fields in `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
labels (see [pod selector](#pod-selector)).
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 67582e9041..2c2fd8c7c2 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -13,8 +13,8 @@ weight: 30
-A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
-[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
+A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}}
+{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}.
You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
@@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th
{{< /note >}}
-
-
## Use Case
@@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib
The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
-The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
-`apiVersion` or `kind`.
+The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
@@ -1155,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-### Rollback To
-
-Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
-
### Revision History Limit
A Deployment's revision history is stored in the ReplicaSets it controls.
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index a20951a35e..79cc905f58 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy`
field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
"Foreground", or "Background".
-Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
-This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
-Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you
-specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1`
-group version, dependent objects are deleted by default.
-
Here's an example that deletes dependents in background:
```shell
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index 21e8aceb64..81c1280943 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a Job must specify appropriate
labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 2cc8284940..d59c09fc6b 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).
diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md
old mode 100755
new mode 100644
index a105f18fb3..c7408721b7
--- a/content/en/docs/concepts/workloads/pods/_index.md
+++ b/content/en/docs/concepts/workloads/pods/_index.md
@@ -1,5 +1,271 @@
---
-title: "Pods"
+reviewers:
+- erictune
+title: Pods
+content_type: concept
weight: 10
+no_list: true
+card:
+ name: concepts
+ weight: 60
---
+
+
+_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
+
+A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
+{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification
+for how to run the containers. A Pod's contents are always co-located and
+co-scheduled, and run in a shared context. A Pod models an
+application-specific "logical host": it contains one or more application
+containers which are relatively tightly coupled.
+In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
+
+As well as application containers, a Pod can contain
+[init containers](/docs/concepts/workloads/pods/init-containers/) that run
+during Pod startup. You can also inject
+[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/)
+for debugging if your cluster offers this.
+
+
+
+## What is a Pod?
+
+{{< note >}}
+While Kubernetes supports more
+{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}}
+than just Docker, [Docker](https://www.docker.com/) is the most commonly known
+runtime, and it helps to describe Pods using some terminology from Docker.
+{{< /note >}}
+
+The shared context of a Pod is a set of Linux namespaces, cgroups, and
+potentially other facets of isolation - the same things that isolate a Docker
+container. Within a Pod's context, the individual applications may have
+further sub-isolations applied.
+
+In terms of Docker concepts, a Pod is similar to a group of Docker containers
+with shared namespaces and shared filesystem volumes.
+
+## Using Pods
+
+Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
+term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
+If your Pods need to track state, consider the
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
+
+Pods in a Kubernetes cluster are used in two main ways:
+
+* **Pods that run a single container**. The "one-container-per-Pod" model is the
+ most common Kubernetes use case; in this case, you can think of a Pod as a
+ wrapper around a single container; Kubernetes manages Pods rather than managing
+ the containers directly.
+* **Pods that run multiple containers that need to work together**. A Pod can
+ encapsulate an application composed of multiple co-located containers that are
+ tightly coupled and need to share resources. These co-located containers
+ form a single cohesive unit of service—for example, one container serving data
+ stored in a shared volume to the public, while a separate _sidecar_ container
+ refreshes or updates those files.
+ The Pod wraps these containers, storage resources, and an ephemeral network
+ identity together as a single unit.
+
+ {{< note >}}
+ Grouping multiple co-located and co-managed containers in a single Pod is a
+ relatively advanced use case. You should use this pattern only in specific
+ instances in which your containers are tightly coupled.
+ {{< /note >}}
+
+Each Pod is meant to run a single instance of a given application. If you want to
+scale your application horizontally (to provide more overall resources by running
+more instances), you should use multiple Pods, one for each instance. In
+Kubernetes, this is typically referred to as _replication_.
+Replicated Pods are usually created and managed as a group by a workload resource
+and its {{< glossary_tooltip text="controller" term_id="controller" >}}.
+
+See [Pods and controllers](#pods-and-controllers) for more information on how
+Kubernetes uses workload resources, and their controllers, to implement application
+scaling and auto-healing.
+
+### How Pods manage multiple containers
+
+Pods are designed to support multiple cooperating processes (as containers) that form
+a cohesive unit of service. The containers in a Pod are automatically co-located and
+co-scheduled on the same physical or virtual machine in the cluster. The containers
+can share resources and dependencies, communicate with one another, and coordinate
+when and how they are terminated.
+
+For example, you might have a container that
+acts as a web server for files in a shared volume, and a separate "sidecar" container
+that updates those files from a remote source, as in the following diagram:
+
+{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
+
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
+
+Pods natively provide two kinds of shared resources for their constituent containers:
+[networking](#pod-networking) and [storage](#pod-storage).
+
+## Working with Pods
+
+You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
+is because Pods are designed as relatively ephemeral, disposable entities. When
+a Pod gets created (directly by you, or indirectly by a
+{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is
+scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster.
+The Pod remains on that node until the Pod finishes execution, the Pod object is deleted,
+the Pod is *evicted* for lack of resources, or the node fails.
+
+{{< note >}}
+Restarting a container in a Pod should not be confused with restarting a Pod. A Pod
+is not a process, but an environment for running container(s). A Pod persists until
+it is deleted.
+{{< /note >}}
+
+When you create the manifest for a Pod object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+### Pods and controllers
+
+You can use workload resources to create and manage multiple Pods for you. A controller
+for the resource handles replication and rollout and automatic healing in case of
+Pod failure. For example, if a Node fails, a controller notices that Pods on that
+Node have stopped working and creates a replacement Pod. The scheduler places the
+replacement Pod onto a healthy Node.
+
+Here are some examples of workload resources that manage one or more Pods:
+
+* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
+* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
+
+### Pod templates
+
+Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
+from a _pod template_ and manage those Pods on your behalf.
+
+PodTemplates are specifications for creating Pods, and are included in workload resources such as
+[Deployments](/docs/concepts/workloads/controllers/deployment/),
+[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
+
+Each controller for a workload resource uses the `PodTemplate` inside the workload
+object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
+workload resource you used to run your app.
+
+The sample below is a manifest for a simple Job with a `template` that starts one
+container. The container in that Pod prints a message then pauses.
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: hello
+spec:
+ template:
+ # This is the pod template
+ spec:
+ containers:
+ - name: hello
+ image: busybox
+ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+ restartPolicy: OnFailure
+ # The pod template ends here
+```
+
+Modifying the pod template or switching to a new pod template has no effect on the
+Pods that already exist. Pods do not receive template updates directly. Instead,
+a new Pod is created to match the revised pod template.
+
+For example, the deployment controller ensures that the running Pods match the current
+pod template for each Deployment object. If the template is updated, the Deployment has
+to remove the existing Pods and create new Pods based on the updated template. Each workload
+resource implements its own rules for handling changes to the Pod template.
+
+On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
+directly observe or manage any of the details around pod templates and updates; those
+details are abstracted away. That abstraction and separation of concerns simplifies
+system semantics, and makes it feasible to extend the cluster's behavior without
+changing existing code.
+
+## Resource sharing and communication
+
+Pods enable data sharing and communication among their constituent
+containters.
+
+### Storage in Pods {#pod-storage}
+
+A Pod can specify a set of shared storage
+{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers
+in the Pod can access the shared volumes, allowing those containers to
+share data. Volumes also allow persistent data in a Pod to survive
+in case one of the containers within needs to be restarted. See
+[Storage](/docs/concepts/storage/) for more information on how
+Kubernetes implements shared storage and makes it available to Pods.
+
+### Pod networking
+
+Each Pod is assigned a unique IP address for each address family. Every
+container in a Pod shares the network namespace, including the IP address and
+network ports. Inside a Pod (and **only** then), the containers that belong to the Pod
+can communicate with one another using `localhost`. When containers in a Pod communicate
+with entities *outside the Pod*,
+they must coordinate how they use the shared network resources (such as ports).
+Within a Pod, containers share an IP address and port space, and
+can find each other via `localhost`. The containers in a Pod can also communicate
+with each other using standard inter-process communications like SystemV semaphores
+or POSIX shared memory. Containers in different Pods have distinct IP addresses
+and can not communicate by IPC without
+[special configuration](/docs/concepts/policy/pod-security-policy/).
+Containers that want to interact with a container running in a different Pod can
+use IP networking to comunicate.
+
+Containers within the Pod see the system hostname as being the same as the configured
+`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
+section.
+
+## Privileged mode for containers
+
+Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
+Processes within a privileged container get almost the same privileges that are available to processes outside a container.
+
+{{< note >}}
+Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
+{{< /note >}}
+
+## Static Pods
+
+_Static Pods_ are managed directly by the kubelet daemon on a specific node,
+without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
+observing them.
+Whereas most Pods are managed by the control plane (for example, a
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static
+Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
+
+Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
+The main use for static Pods is to run a self-hosted control plane: in other words,
+using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
+
+The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
+on the Kubernetes API server for each static Pod.
+This means that the Pods running on a node are visible on the API server,
+but cannot be controlled from there.
+
+## {{% heading "whatsnext" %}}
+
+* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
+* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
+* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
+ configure different Pods with different container runtime configurations.
+* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
+* Pod is a top-level resource in the Kubernetes REST API.
+ The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+ object definition describes the object in detail.
+* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
+
+To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
+ * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+ * [Borg](https://research.google.com/pubs/pub43438.html)
+ * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+ * [Omega](https://research.google/pubs/pub41684/)
+ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md
index 589bde5668..0810b6fec7 100644
--- a/content/en/docs/concepts/workloads/pods/disruptions.md
+++ b/content/en/docs/concepts/workloads/pods/disruptions.md
@@ -11,17 +11,15 @@ weight: 60
This guide is for application owners who want to build
highly available applications, and thus need to understand
-what types of Disruptions can happen to Pods.
+what types of disruptions can happen to Pods.
-It is also for Cluster Administrators who want to perform automated
+It is also for cluster administrators who want to perform automated
cluster actions, like upgrading and autoscaling clusters.
-
-
-## Voluntary and Involuntary Disruptions
+## Voluntary and involuntary disruptions
Pods do not disappear until someone (a person or a controller) destroys them, or
there is an unavoidable hardware or system software error.
@@ -48,7 +46,7 @@ Administrator. Typical application owner actions include:
- updating a deployment's pod template causing a restart
- directly deleting a pod (e.g. by accident)
-Cluster Administrator actions include:
+Cluster administrator actions include:
- [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade.
- Draining a node from a cluster to scale the cluster down (learn about
@@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa
deleting deployments or pods bypasses Pod Disruption Budgets.
{{< /caution >}}
-## Dealing with Disruptions
+## Dealing with disruptions
Here are some ways to mitigate involuntary disruptions:
@@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and
Your cluster administrator or hosting provider should have documented what level of voluntary
disruptions, if any, to expect.
-Kubernetes offers features to help run highly available applications at the same
-time as frequent voluntary disruptions. We call this set of features
-*Disruption Budgets*.
-
-## How Disruption Budgets Work
+## Pod disruption budgets
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
-An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
-A PDB limits the number of pods of a replicated application that are down simultaneously from
-voluntary disruptions. For example, a quorum-based application would
+Kubernetes offers features to help you run highly available applications even when you
+introduce frequent voluntary disruptions.
+
+As an application owner, you can create a PodDisruptionBudget (PDB) for each application.
+A PDB limits the number of Pods of a replicated application that are down simultaneously from
+voluntary disruptions. For example, a quorum-based application would
like to ensure that the number of replicas running is never brought below the
number needed for a quorum. A web front end might want to
ensure that the number of replicas serving load never falls below a certain
percentage of the total.
Cluster managers and hosting providers should use tools which
-respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
-instead of directly deleting pods or deployments. Examples are the `kubectl drain` command
-and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
+respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
+instead of directly deleting pods or deployments.
-When a cluster administrator wants to drain a node
-they use the `kubectl drain` command. That tool tries to evict all
-the pods on the machine. The eviction request may be temporarily rejected,
-and the tool periodically retries all failed requests until all pods
-are terminated, or until a configurable timeout is reached.
+For example, the `kubectl drain` subcommand lets you mark a node as going out of
+service. When you run `kubectl drain`, the tool tries to evict all of the Pods on
+the Node you're taking out of service. The eviction request that `kubectl` submits on
+your behalf may be temporarily rejected, so the tool periodically retries all failed
+requests until all Pods on the target node are terminated, or until a configurable timeout
+is reached.
A PDB specifies the number of replicas that an application can tolerate having, relative to how
many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is
supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time,
-then the Eviction API will allow voluntary disruption of one, but not two pods, at a time.
+then the Eviction API will allow voluntary disruption of one (but not two) pods at a time.
The group of pods that comprise the application is specified using a label selector, the same
as the one used by the application's controller (deployment, stateful-set, etc).
-The "intended" number of pods is computed from the `.spec.replicas` of the pods controller.
-The controller is discovered from the pods using the `.metadata.ownerReferences` of the object.
+The "intended" number of pods is computed from the `.spec.replicas` of the workload resource
+that is managing those pods. The control plane discovers the owning workload resource by
+examining the `.metadata.ownerReferences` of the Pod.
PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from
occurring, but they do count against the budget.
Pods which are deleted or unavailable due to a rolling upgrade to an application do count
-against the disruption budget, but controllers (like deployment and stateful-set)
-are not limited by PDBs when doing rolling upgrades -- the handling of failures
-during application updates is configured in the controller spec.
-(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+against the disruption budget, but workload resources (such as Deployment and StatefulSet)
+are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures
+during application updates is configured in the spec for the specific workload resource.
-When a pod is evicted using the eviction API, it is gracefully terminated (see
-`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
+When a pod is evicted using the eviction API, it is gracefully
+[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the
+`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
-## PDB Example
+## PodDisruptionBudget example {#pdb-example}
Consider a cluster with 3 nodes, `node-1` through `node-3`.
The cluster is running several applications. One of them has 3 replicas initially called
@@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
+* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
+ including steps to maintain its availability during the rollout.
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index d72265faf5..2b292d376d 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -6,16 +6,60 @@ weight: 30
-{{< comment >}}Updated: 4/14/2015{{< /comment >}}
-{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
-
-This page describes the lifecycle of a Pod.
+This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting
+in the `Pending` [phase](#pod-phase), moving through `Running` if at least one
+of its primary containers starts OK, and then through either the `Succeeded` or
+`Failed` phases depending on whether any container in the Pod terminated in failure.
+Whilst a Pod is running, the kubelet is able to restart containers to handle some
+kind of faults. Within a Pod, Kubernetes tracks different container
+[states](#container-states) and handles
+In the Kubernetes API, Pods have both a specification and an actual status. The
+status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
+You can also inject [custom readiness information](#pod-readiness-gate) into the
+condition data for a Pod, if that is useful to your application.
+Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime.
+Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops
+or is [terminated](#pod-termination).
+## Pod lifetime
+
+Like individual application containers, Pods are considered to be relatively
+ephemeral (rather than durable) entities. Pods are created, assigned a unique
+ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
+to nodes where they remain until termination (according to restart policy) or
+deletion.
+If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
+are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
+
+Pods do not, by themselves, self-heal. If a Pod is scheduled to a
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
+or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
+survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
+higher-level abstraction, called a
+{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of
+managing the relatively disposable Pod instances.
+
+A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
+that Pod can be replaced by a new, near-identical Pod, with even the same name i
+desired, but with a different UID.
+
+When something is said to have the same lifetime as a Pod, such as a
+{{< glossary_tooltip term_id="volume" text="volume" >}},
+that means that the thing exists as long as that specific Pod (with that exact UID)
+exists. If that Pod is deleted for any reason, and even if an identical replacement
+is created, the related thing (a volume, in this example) is also destroyed and
+created anew.
+
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+
+*A multi-container Pod that contains a file puller and a
+web server that uses a persistent volume for shared storage between the containers.*
+
## Pod phase
A Pod's `status` field is a
@@ -24,7 +68,7 @@ object, which has a `phase` field.
The phase of a Pod is a simple, high-level summary of where the Pod is in its
lifecycle. The phase is not intended to be a comprehensive rollup of observations
-of Container or Pod state, nor is it intended to be a comprehensive state machine.
+of container or Pod state, nor is it intended to be a comprehensive state machine.
The number and meanings of Pod phase values are tightly guarded.
Other than what is documented here, nothing should be assumed about Pods that
@@ -34,188 +78,106 @@ Here are the possible values for `phase`:
Value | Description
:-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
-`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting.
-`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted.
-`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
-`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.
+`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
+`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
+`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
+`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
+`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
+
+If a node dies or is disconnected from the rest of the cluster, Kubernetes
+applies a policy for setting the `phase` of all Pods on the lost node to Failed.
+
+## Container states
+
+As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of
+each container inside a Pod. You can use
+[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to
+trigger events to run at certain points in a container's lifecycle.
+
+Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}
+assigns a Pod to a Node, the kubelet starts creating containers for that Pod
+using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
+There are three possible container states: `Waiting`, `Running`, and `Terminated`.
+
+To the check state of a Pod's containers, you can use
+`kubectl describe pod `. The output shows the state for each container
+within that Pod.
+
+Each state has a specific meaning:
+
+### `Waiting` {#container-state-waiting}
+
+If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+A container in the `Waiting` state is still running the operations it requires in
+order to complete start up: for example, pulling the container image from a container
+image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
+data.
+When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see
+a Reason field to summarize why the container is in that state.
+
+### `Running` {#container-state-running}
+
+The `Running` status indicates that a container is executing without issues. If there
+was a `postStart` hook configured, it has already executed and executed. When you use
+`kubectl` to query a Pod with a container that is `Running`, you also see information
+about when the container entered the `Running` state.
+
+### `Terminated` {#container-state-terminated}
+
+A container in the `Terminated` state has begin execution and has then either run to
+completion or has failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, and exit code, and the start and
+finish time for that container's period of execution.
+
+If a container has a `preStop` hook configured, that runs before the container enters
+the `Terminated` state.
+
+## Container restart policy {#restart-policy}
+
+The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure,
+and Never. The default value is Always.
+
+The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
+refers to restarts of the containers by the kubelet on the same node. After containers
+in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
+40s, …), that is capped at five minutes. Once a container has executed with no problems
+for 10 minutes without any problems, the kubelet resets the restart backoff timer for
+that container.
## Pod conditions
A Pod has a PodStatus, which has an array of
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)
-through which the Pod has or has not passed. Each element of the PodCondition
-array has six possible fields:
+through which the Pod has or has not passed:
-* The `lastProbeTime` field provides a timestamp for when the Pod condition
- was last probed.
+* `PodScheduled`: the Pod has been scheduled to a node.
+* `ContainersReady`: all containers in the Pod are ready.
+* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
+ have started successfully.
+* `Ready`: the Pod is able to serve requests and should be added to the load
+ balancing pools of all matching Services.
-* The `lastTransitionTime` field provides a timestamp for when the Pod
- last transitioned from one status to another.
-
-* The `message` field is a human-readable message indicating details
- about the transition.
-
-* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition.
-
-* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`".
-
-* The `type` field is a string with the following possible values:
-
- * `PodScheduled`: the Pod has been scheduled to a node;
- * `Ready`: the Pod is able to serve requests and should be added to the load
- balancing pools of all matching Services;
- * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
- have started successfully;
- * `ContainersReady`: all containers in the Pod are ready.
+Field name | Description
+:--------------------|:-----------
+`type` | Name of this Pod condition.
+`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`".
+`lastProbeTime` | Timestamp of when the Pod condition was last probed.
+`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another.
+`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition.
+`message` | Human-readable message indicating details about the last status transition.
-
-## Container probes
-
-A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
-on a Container. To perform a diagnostic,
-the kubelet calls a
-[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
-the Container. There are three types of handlers:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
- Executes a specified command inside the Container. The diagnostic
- is considered successful if the command exits with a status code of 0.
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
- Performs a TCP check against the Container's IP address on
- a specified port. The diagnostic is considered successful if the port is open.
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
- Performs an HTTP Get request against the Container's IP
- address on a specified port and path. The diagnostic is considered successful
- if the response has a status code greater than or equal to 200 and less than 400.
-
-Each probe has one of three results:
-
-* Success: The Container passed the diagnostic.
-* Failure: The Container failed the diagnostic.
-* Unknown: The diagnostic failed, so no action should be taken.
-
-The kubelet can optionally perform and react to three kinds of probes on running
-Containers:
-
-* `livenessProbe`: Indicates whether the Container is running. If
- the liveness probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a liveness probe, the default state is `Success`.
-
-* `readinessProbe`: Indicates whether the Container is ready to service requests.
- If the readiness probe fails, the endpoints controller removes the Pod's IP
- address from the endpoints of all Services that match the Pod. The default
- state of readiness before the initial delay is `Failure`. If a Container does
- not provide a readiness probe, the default state is `Success`.
-
-* `startupProbe`: Indicates whether the application within the Container is started.
- All other probes are disabled if a startup probe is provided, until it succeeds.
- If the startup probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a startup probe, the default state is `Success`.
-
-### When should you use a liveness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If the process in your Container is able to crash on its own whenever it
-encounters an issue or becomes unhealthy, you do not necessarily need a liveness
-probe; the kubelet will automatically perform the correct action in accordance
-with the Pod's `restartPolicy`.
-
-If you'd like your Container to be killed and restarted if a probe fails, then
-specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
-
-### When should you use a readiness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If you'd like to start sending traffic to a Pod only when a probe succeeds,
-specify a readiness probe. In this case, the readiness probe might be the same
-as the liveness probe, but the existence of the readiness probe in the spec means
-that the Pod will start without receiving any traffic and only start receiving
-traffic after the probe starts succeeding.
-If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe.
-
-If you want your Container to be able to take itself down for maintenance, you
-can specify a readiness probe that checks an endpoint specific to readiness that
-is different from the liveness probe.
-
-Note that if you just want to be able to drain requests when the Pod is deleted,
-you do not necessarily need a readiness probe; on deletion, the Pod automatically
-puts itself into an unready state regardless of whether the readiness probe exists.
-The Pod remains in the unready state while it waits for the Containers in the Pod
-to stop.
-
-### When should you use a startup probe?
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s.
-You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.
-
-For more information about how to set up a liveness, readiness, startup probe, see
-[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-## Pod and Container status
-
-For detailed information about Pod Container status, see
-[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
-and
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-Note that the information reported as Pod status depends on the current
-[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-
-## Container States
-
-Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod.
-
-* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information.
-
- ```yaml
- ...
- State: Waiting
- Reason: ErrImagePull
- ...
- ```
-
-* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state.
-
- ```yaml
- ...
- State: Running
- Started: Wed, 30 Jan 2019 16:46:38 +0530
- ...
- ```
-
-* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed.
-
- ```yaml
- ...
- State: Terminated
- Reason: Completed
- Exit Code: 0
- Started: Wed, 30 Jan 2019 11:45:26 +0530
- Finished: Wed, 30 Jan 2019 11:45:26 +0530
- ...
- ```
-
-## Pod readiness {#pod-readiness-gate}
+### Pod readiness {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
Your application can inject extra feedback or signals into PodStatus:
-_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify
-a list of additional conditions that the kubelet evaluates for Pod readiness.
+_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to
+specify a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
-fields for the Pod. If Kubernetes cannot find such a
-condition in the `status.conditions` field of a Pod, the status of the condition
+fields for the Pod. If Kubernetes cannot find such a condition in the
+`status.conditions` field of a Pod, the status of the condition
is defaulted to "`False`".
Here is an example:
@@ -258,152 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only*
when both the following statements apply:
* All containers in the Pod are ready.
-* All conditions specified in `ReadinessGates` are `True`.
+* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
-`False`, the kubelet sets the Pod's condition to `ContainersReady`.
+`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
-## Restart policy
+## Container probes
-A PodSpec has a `restartPolicy` field with possible values Always, OnFailure,
-and Never. The default value is Always.
-`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only
-refers to restarts of the Containers by the kubelet on the same node. Exited
-Containers that are restarted by the kubelet are restarted with an exponential
-back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten
-minutes of successful execution. As discussed in the
-[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
-once bound to a node, a Pod will never be rebound to another node.
+A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
+performed periodically by the [kubelet](/docs/admin/kubelet/)
+on a Container. To perform a diagnostic,
+the kubelet calls a
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
+the container. There are three types of handlers:
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+ Executes a specified command inside the container. The diagnostic
+ is considered successful if the command exits with a status code of 0.
-## Pod lifetime
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+ Performs a TCP check against the Pod's IP address on
+ a specified port. The diagnostic is considered successful if the port is open.
-In general, Pods remain until a human or
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+ Performs an HTTP `GET` request against the Pod's IP
+ address on a specified port and path. The diagnostic is considered successful
+ if the response has a status code greater than or equal to 200 and less than 400.
+
+Each probe has one of three results:
+
+* `Success`: The container passed the diagnostic.
+* `Failure`: The container failed the diagnostic.
+* `Unknown`: The diagnostic failed, so no action should be taken.
+
+The kubelet can optionally perform and react to three kinds of probes on running
+containers:
+
+* `livenessProbe`: Indicates whether the container is running. If
+ the liveness probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a liveness probe, the default state is `Success`.
+
+* `readinessProbe`: Indicates whether the container is ready to respond to requests.
+ If the readiness probe fails, the endpoints controller removes the Pod's IP
+ address from the endpoints of all Services that match the Pod. The default
+ state of readiness before the initial delay is `Failure`. If a Container does
+ not provide a readiness probe, the default state is `Success`.
+
+* `startupProbe`: Indicates whether the application within the container is started.
+ All other probes are disabled if a startup probe is provided, until it succeeds.
+ If the startup probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a startup probe, the default state is `Success`.
+
+For more information about how to set up a liveness, readiness, or startup probe,
+see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+
+### When should you use a liveness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If the process in your container is able to crash on its own whenever it
+encounters an issue or becomes unhealthy, you do not necessarily need a liveness
+probe; the kubelet will automatically perform the correct action in accordance
+with the Pod's `restartPolicy`.
+
+If you'd like your container to be killed and restarted if a probe fails, then
+specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
+
+### When should you use a readiness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If you'd like to start sending traffic to a Pod only when a probe succeeds,
+specify a readiness probe. In this case, the readiness probe might be the same
+as the liveness probe, but the existence of the readiness probe in the spec means
+that the Pod will start without receiving any traffic and only start receiving
+traffic after the probe starts succeeding.
+If your container needs to work on loading large data, configuration files, or
+migrations during startup, specify a readiness probe.
+
+If you want your container to be able to take itself down for maintenance, you
+can specify a readiness probe that checks an endpoint specific to readiness that
+is different from the liveness probe.
+
+{{< note >}}
+If you just want to be able to drain requests when the Pod is deleted, you do not
+necessarily need a readiness probe; on deletion, the Pod automatically puts itself
+into an unready state regardless of whether the readiness probe exists.
+The Pod remains in the unready state while it waits for the containers in the Pod
+to stop.
+{{< /note >}}
+
+### When should you use a startup probe?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Startup probes are useful for Pods that have containers that take a long time to
+come into service. Rather than set a long liveness interval, you can configure
+a separate configuration for probing the container as it starts up, allowing
+a time longer than the liveness interval would allow.
+
+If your container usually starts in more than
+`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a
+startup probe that checks the same endpoint as the liveness probe. The default for
+`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to
+allow the container to start, without changing the default values of the liveness
+probe. This helps to protect against deadlocks.
+
+## Termination of Pods {#pod-termination}
+
+Because Pods represent processes running on nodes in the cluster, it is important to
+allow those processes to gracefully terminate when they are no longer needed (rather
+than being abruptly stopped with a `KILL` signal and having no chance to clean up).
+
+The design aim is for you to be able to request deletion and know when processes
+terminate, but also be able to ensure that deletes eventually complete.
+When you request deletion of a Pod, the cluster records and tracks the intended grace period
+before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in
+place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
+shutdown.
+
+Typically, the container runtime sends a a TERM signal is sent to the main process in each
+container. Once the grace period has expired, the KILL signal is sent to any remainig
+processes, and the Pod is then deleted from the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
+container runtime's management service is restarted while waiting for processes to terminate, the
+cluster retries from the start including the full original grace period.
+
+An example flow:
+
+1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
+ (30 seconds).
+1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
+ along with the grace period.
+ If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
+ "Terminating".
+ On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
+ as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
+ shutdown process.
+ 1. If one of the Pod's containers has defined a `preStop`
+ [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
+ runs that hook inside of the container. If the `preStop` hook is still running after the
+ grace period expires, the kubelet requests a small, one-off grace period extension of 2
+ seconds.
+ {{< note >}}
+ If the `preStop` hook needs longer to complete than the default grace period allows,
+ you must modify `terminationGracePeriodSeconds` to suit this.
+ {{< /note >}}
+ 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
+ container.
+ {{< note >}}
+ The containers in the Pod receive the TERM signal at different times and in an arbitrary
+ order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
+ {{< /note >}}
+1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that
+ shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent
+ a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured
+ {{< glossary_tooltip text="selector" term_id="selector" >}}.
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources
+ no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly
+ cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from
+ the list of endpoints as soon as the termination grace period _begins_.
+1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends
+ `SIGKILL` to any processes still running in any container in the Pod.
+ The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
+1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
+ to 0 (immediate deletion).
+1. The API server deletes the Pod's API object, which is then no longer visible from any client.
+
+### Forced Pod termination {#pod-termination-forced}
+
+{{< caution >}}
+Forced deletions can be potentially disruptiove for some workloads and their Pods.
+{{< /caution >}}
+
+By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
+the `--grace-period=` option which allows you to override the default and specify your
+own value.
+
+Setting the grace period to `0` forcibly and immediately deletes the Pod from the API
+server. If the pod was still running on a node, that forcible deletion triggers the kubelet to
+begin immediate cleanup.
+
+{{< note >}}
+You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+{{< /note >}}
+
+When a force deletion is performed, the API server does not wait for confirmation
+from the kubelet that the Pod has been terminated on the node it was running on. It
+removes the Pod in the API immediately so a new Pod can be created with the same
+name. On the node, Pods that are set to terminate immediately will still be given
+a small grace period before being force killed.
+
+If you need to force-delete Pods that are part of a StatefulSet, refer to the task
+documentation for
+[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+
+### Garbage collection of failed Pods {#pod-garbage-collection}
+
+For failed Pods, the API objects remain in the cluster's API until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process
explicitly removes them.
+
The control plane cleans up terminated Pods (with a phase of `Succeeded` or
`Failed`), when the number of Pods exceeds the configured threshold
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
This avoids a resource leak as Pods are created and terminated over time.
-There are different kinds of resources for creating Pods:
-
-- Use a {{< glossary_tooltip term_id="deployment" >}},
- {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}}
- for Pods that are not expected to terminate, for example, web servers.
-
-- Use a {{< glossary_tooltip term_id="job" >}}
- for Pods that are expected to terminate once their work is complete;
- for example, batch computations. Jobs are appropriate only for Pods with
- `restartPolicy` equal to OnFailure or Never.
-
-- Use a {{< glossary_tooltip term_id="daemonset" >}}
- for Pods that need to run one per eligible node.
-
-All workload resources contain a PodSpec. It is recommended to create the
-appropriate workload resource and let the resource's controller create Pods
-for you, rather than directly create Pods yourself.
-
-If a node dies or is disconnected from the rest of the cluster, Kubernetes
-applies a policy for setting the `phase` of all Pods on the lost node to Failed.
-
-## Examples
-
-### Advanced liveness probe example
-
-Liveness probes are executed by the kubelet, so all requests are made in the
-kubelet network namespace.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- labels:
- test: liveness
- name: liveness-http
-spec:
- containers:
- - args:
- - /server
- image: k8s.gcr.io/liveness
- livenessProbe:
- httpGet:
- # when "host" is not defined, "PodIP" will be used
- # host: my-host
- # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
- # scheme: HTTPS
- path: /healthz
- port: 8080
- httpHeaders:
- - name: X-Custom-Header
- value: Awesome
- initialDelaySeconds: 15
- timeoutSeconds: 1
- name: liveness
-```
-
-### Example states
-
- * Pod is running and has one Container. Container exits with success.
- * Log completion event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Pod `phase` becomes Succeeded.
- * Never: Pod `phase` becomes Succeeded.
-
- * Pod is running and has one Container. Container exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has two Containers. Container 1 exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Do not restart Container; Pod `phase` stays Running.
- * If Container 1 is not running, and Container 2 exits:
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has one Container. Container runs out of memory.
- * Container terminates in failure.
- * Log OOM event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Log failure event; Pod `phase` becomes Failed.
-
- * Pod is running, and a disk dies.
- * Kill all Containers.
- * Log appropriate event.
- * Pod `phase` becomes Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
- * Pod is running, and its node is segmented out.
- * Node controller waits for timeout.
- * Node controller sets Pod `phase` to Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
-
-
## {{% heading "whatsnext" %}}
-
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
* Get hands-on experience
- [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-
+ [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
+* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+and
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
deleted file mode 100644
index e963b7ace6..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-reviewers:
-- erictune
-title: Pod Overview
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 60
----
-
-
-This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-
-
-
-
-## Understanding Pods
-
-A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
-
-A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
-
-[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
-
-
-Pods in a Kubernetes cluster can be used in two main ways:
-
-* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
-* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-
-Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_.
-Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}.
-See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing.
-
-### How Pods manage multiple containers
-
-Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
-
-Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
-
-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
-
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-
-Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
-
-#### Networking
-
-Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
-
-#### Storage
-
-A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
-
-## Working with Pods
-
-You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails.
-
-{{< note >}}
-Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted.
-{{< /note >}}
-
-Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller.
-
-### Pods and controllers
-
-You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node.
-
-Here are some examples of workload resources that manage one or more Pods:
-
-* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
-* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
-* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
-
-
-## Pod templates
-
-Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
-from a pod template and manage those Pods on your behalf.
-
-PodTemplates are specifications for creating Pods, and are included in workload resources such as
-[Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
-[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
-
-Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app.
-
-The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: hello
-spec:
- template:
- # This is the pod template
- spec:
- containers:
- - name: hello
- image: busybox
- command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
- restartPolicy: OnFailure
- # The pod template ends here
-```
-
-Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template.
-
-For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template.
-
-On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
-
-
-
-## {{% heading "whatsnext" %}}
-
-* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
-* Learn more about Pod behavior:
- * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 650280a82f..9982ac7240 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,7 +1,7 @@
---
title: Pod Topology Spread Constraints
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index d87dc92cb2..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-reviewers:
-title: Pods
-content_type: concept
-weight: 20
----
-
-
-
-_Pods_ are the smallest deployable units of computing that can be created and
-managed in Kubernetes.
-
-
-
-
-
-
-## What is a Pod?
-
-A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
-{{< glossary_tooltip text="containers" term_id="container" >}} (such as
-Docker containers), with shared storage/network, and a specification
-for how to run the containers. A Pod's contents are always co-located and
-co-scheduled, and run in a shared context. A Pod models an
-application-specific "logical host" - it contains one or more application
-containers which are relatively tightly coupled — in a pre-container
-world, being executed on the same physical or virtual machine would mean being
-executed on the same logical host.
-
-While Kubernetes supports more container runtimes than just Docker, Docker is
-the most commonly known runtime, and it helps to describe Pods in Docker terms.
-
-The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a Docker
-container. Within a Pod's context, the individual applications may have
-further sub-isolations applied.
-
-Containers within a Pod share an IP address and port space, and
-can find each other via `localhost`. They can also communicate with each
-other using standard inter-process communications like SystemV semaphores or
-POSIX shared memory. Containers in different Pods have distinct IP addresses
-and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
-These containers usually communicate with each other via Pod IP addresses.
-
-Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
-as part of a Pod and are made available to be mounted into each application's
-filesystem.
-
-In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
-a group of Docker containers with shared namespaces and shared filesystem
-volumes.
-
-Like individual application containers, Pods are considered to be relatively
-ephemeral (rather than durable) entities. As discussed in
-[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
-scheduled to nodes where they remain until termination (according to restart
-policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
-scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
-"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
-with even the same name if desired, but with a new UID (see [replication
-controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
-
-When something is said to have the same lifetime as a Pod, such as a volume,
-that means that it exists as long as that Pod (with that UID) exists. If that
-Pod is deleted for any reason, even if an identical replacement is created, the
-related thing (e.g. volume) is also destroyed and created anew.
-
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
-
-*A multi-container Pod that contains a file puller and a
-web server that uses a persistent volume for shared storage between the containers.*
-
-## Motivation for Pods
-
-### Management
-
-Pods are a model of the pattern of multiple cooperating processes which form a
-cohesive unit of service. They simplify application deployment and management
-by providing a higher-level abstraction than the set of their constituent
-applications. Pods serve as unit of deployment, horizontal scaling, and
-replication. Colocation (co-scheduling), shared fate (e.g. termination),
-coordinated replication, resource sharing, and dependency management are
-handled automatically for containers in a Pod.
-
-### Resource sharing and communication
-
-Pods enable data sharing and communication among their constituents.
-
-The applications in a Pod all use the same network namespace (same IP and port
-space), and can thus "find" each other and communicate using `localhost`.
-Because of this, applications in a Pod must coordinate their usage of ports.
-Each Pod has an IP address in a flat shared networking space that has full
-communication with other physical computers and Pods across the network.
-
-Containers within the Pod see the system hostname as being the same as the configured
-`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
-section.
-
-In addition to defining the application containers that run in the Pod, the Pod
-specifies a set of shared storage volumes. Volumes enable data to survive
-container restarts and to be shared among the applications within the Pod.
-
-## Uses of pods
-
-Pods can be used to host vertically integrated application stacks (e.g. LAMP),
-but their primary motivation is to support co-located, co-managed helper
-programs, such as:
-
-* content management systems, file and data loaders, local cache managers, etc.
-* log and checkpoint backup, compression, rotation, snapshotting, etc.
-* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
-* proxies, bridges, and adapters
-* controllers, managers, configurators, and updaters
-
-Individual Pods are not intended to run multiple instances of the same
-application, in general.
-
-For a longer explanation, see [The Distributed System ToolKit: Patterns for
-Composite
-Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
-
-## Alternatives considered
-
-_Why not just run multiple programs in a single (Docker) container?_
-
-1. Transparency. Making the containers within the Pod visible to the
- infrastructure enables the infrastructure to provide services to those
- containers, such as process management and resource monitoring. This
- facilitates a number of conveniences for users.
-1. Decoupling software dependencies. The individual containers may be
- versioned, rebuilt and redeployed independently. Kubernetes may even support
- live updates of individual containers someday.
-1. Ease of use. Users don't need to run their own process managers, worry about
- signal and exit-code propagation, etc.
-1. Efficiency. Because the infrastructure takes on more responsibility,
- containers can be lighter weight.
-
-_Why not support affinity-based co-scheduling of containers?_
-
-That approach would provide co-location, but would not provide most of the
-benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
-simplified management.
-
-## Durability of pods (or lack thereof)
-
-Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
-
-In general, users shouldn't need to create Pods directly. They should almost
-always use controllers even for singletons, for example,
-[Deployments](/docs/concepts/workloads/controllers/deployment/).
-Controllers provide self-healing with a cluster scope, as well as replication
-and rollout management.
-Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
-can also provide support to stateful Pods.
-
-The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
-
-Pod is exposed as a primitive in order to facilitate:
-
-* scheduler and controller pluggability
-* support for pod-level operations without the need to "proxy" them via controller APIs
-* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
-* decoupling of controllers and services — the endpoint controller just watches Pods
-* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
-* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
-
-## Termination of Pods
-
-Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
-
-An example flow:
-
-1. User sends command to delete Pod, with default grace period (30s)
-1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
-1. Pod shows up as "Terminating" when listed in client commands
-1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
- 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete.
- 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
-1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
-1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
-1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
-
-By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
-You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
-
-### Force deletion of pods
-
-Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-
-Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-
-## Privileged mode for pod containers
-
-Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
-
-{{< note >}}
-Your container runtime must support the concept of a privileged container for this setting to be relevant.
-{{< /note >}}
-
-## API Object
-
-Pod is a top-level resource in the Kubernetes REST API.
-The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
-describes the object in detail.
-When creating the manifest for a Pod object, make sure the name specified is a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
-
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index f77e34a3f9..9cbb7bdff8 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -1,7 +1,7 @@
---
reviewers:
- jessfraz
-title: Pod Preset
+title: Pod Presets
content_type: concept
weight: 50
---
@@ -32,20 +32,20 @@ specific service do not need to know all the details about that service.
In order to use Pod presets in your cluster you must ensure the following:
-1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
- example, this can be done by including `settings.k8s.io/v1alpha1=true` in
- the `--runtime-config` option for the API server. In minikube add this flag
- `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
- starting the cluster.
-1. You have enabled the admission controller `PodPreset`. One way to doing this
- is to include `PodPreset` in the `--enable-admission-plugins` option value specified
- for the API server. In minikube, add this flag
-
- ```shell
- --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
- ```
-
- while starting the cluster.
+1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
+ example, this can be done by including `settings.k8s.io/v1alpha1=true` in
+ the `--runtime-config` option for the API server. In minikube add this flag
+ `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
+ starting the cluster.
+1. You have enabled the admission controller named `PodPreset`. One way to doing this
+ is to include `PodPreset` in the `--enable-admission-plugins` option value specified
+ for the API server. For example, if you use Minikube, add this flag:
+
+ ```shell
+ --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+ ```
+
+ while starting your cluster.
## How it works
@@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following:
modified by a `PodPreset`. The annotation is of the form
`podpreset.admission.kubernetes.io/podpreset-: ""`.
-Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be
-applied to zero or more pods. When a `PodPreset` is applied to one or more
-Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
-`VolumeMounts`, Kubernetes modifies the container spec for all containers in
-the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
+Each Pod can be matched by zero or more PodPresets; and each PodPreset can be
+applied to zero or more Pods. When a PodPreset is applied to one or more
+Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and
+`volumeMounts`, Kubernetes modifies the container spec for all containers in
+the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec.
{{< note >}}
A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
-- The `.spec.containers` field.
-- The `initContainers` field (requires Kubernetes version 1.14.0 or later).
+- The `.spec.containers` field
+- The `.spec.initContainers` field
{{< /note >}}
-### Disable Pod Preset for a Specific Pod
+### Disable Pod Preset for a specific pod
There may be instances where you wish for a Pod to not be altered by any Pod
-Preset mutations. In these cases, you can add an annotation in the Pod Spec
+preset mutations. In these cases, you can add an annotation in the Pod's `.spec`
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
-
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
-
-
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index d8f57e5e82..cd1b03efd4 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -28,41 +28,62 @@ Kubernetes documentation welcomes improvements from all contributors, new and ex
## Getting started
-Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community.
+Anyone can open an issue about documentation, or contribute a change with a
+pull request (PR) to the
+[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website).
+You need to be comfortable with
+[git](https://git-scm.com/) and
+[GitHub](https://lab.github.com/)
+to work effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
-3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
+1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+ and the website's [static site generator](https://gohugo.io).
+1. Make sure you understand the basic processes for
+ [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
+ [reviewing changes](/docs/contribute/review/reviewing-prs/).
Some tasks require more trust and more access in the Kubernetes organization.
-See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
+See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
roles and permissions.
## Your first contribution
-- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
-- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points.
-- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
-- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
-- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
+- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
+ learn about the different ways you can contribute.
+- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
+ for issues that make good entry points.
+- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
+ to existing documentation and learn more about filing issues in GitHub.
+- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other
+ Kubernetes community members for accuracy and language.
+- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and
+ [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Learn about [page content types](/docs/contribute/style/page-content-types/)
+ and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
-- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository.
+- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo)
+ of the repository.
- Document [features in a release](/docs/contribute/new-content/new-features/).
-- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities).
+- Participate in [SIG Docs](/docs/contribute/participate/), and become a
+ [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/).
+
- Start or help with a [localization](/docs/contribute/localization/).
## Get involved with SIG Docs
-[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project.
+[SIG Docs](/docs/contribute/participate/) is the group of contributors who
+publish and maintain Kubernetes documentation and the website. Getting
+involved with SIG Docs is a great way for Kubernetes contributors (feature
+development or otherwise) to have a large impact on the Kubernetes project.
SIG Docs communicates with different methods:
-- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to
+- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 4c6a3f415a..52ae7b0efd 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -13,13 +13,12 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-
-
## Propose improvements
-SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
+SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members)
+can propose improvements.
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
@@ -42,8 +41,8 @@ documentation testing might involve working with sig-testing.
## Coordinate docs for a Kubernetes release
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
-docs for a Kubernetes release.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can coordinate docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
@@ -73,8 +72,8 @@ rotated among SIG Docs approvers.
## Serve as a New Contributor Ambassador
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
-New Contributor Ambassadors.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve as New Contributor Ambassadors.
New Contributor Ambassadors welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
@@ -92,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
## Sponsor a new contributor
-SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
-new contributors.
+SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers)
+can sponsor new contributors.
After a new contributor has successfully submitted 5 substantive pull requests
to one or more Kubernetes repositories, they are eligible to apply for
-[membership](/docs/contribute/participating#members) in the Kubernetes
-organization. The contributor's membership needs to be backed by two sponsors
-who are already reviewers.
+[membership](/docs/contribute/participate/roles-and-responsibilities/#members)
+in the Kubernetes organization. The contributor's membership needs to be
+backed by two sponsors who are already reviewers.
New docs contributors can request sponsors by asking in the #sig-docs channel
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
@@ -111,7 +110,8 @@ membership in the Kubernetes organization.
## Serve as a SIG Co-chair
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve a term as a co-chair of SIG Docs.
### Prerequisites
@@ -120,7 +120,12 @@ Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
-- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
+- Understand how other Kubernetes SIGs and repositories affect the SIG Docs
+ workflow, including:
+ [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+ [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
+ plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
+ [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
### Responsibilities
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index a1fed1642e..ea6065472e 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -15,21 +15,16 @@ like
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
This topic does not show how to generate the
-[kubectl](/docs/reference/generated/kubectl/kubectl/)
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
options reference page. For instructions on how to generate the kubectl options
reference page, see
-[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
+[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/).
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Setting up the local repositories
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index f68d81dfb4..f2ec01d8e8 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -194,16 +194,14 @@ The use of `make docker-serve` is deprecated. Please use `make container-serve`
In `` run `git add` and `git commit` to commit the change.
Submit your changes as a
-[pull request](/docs/contribute/start/) to the
+[pull request](/docs/contribute/new-content/open-a-pr/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-
## {{% heading "whatsnext" %}}
-
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
index a777fb77e5..c719920813 100644
--- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
+++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
@@ -18,4 +18,5 @@
- You need to know how to create a pull request to a GitHub repository.
This involves creating your own fork of the repository. For more
- information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
+ information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo).
+
diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md
index df5cdbb95f..0790f7925a 100644
--- a/content/en/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md
@@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Getting the docs repository
@@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps:
the sections in the `kubectl` command reference.
When the generated files are in your local clone of the ``
-repository, you can submit them in a [pull request](/docs/contribute/start/)
+repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/)
to ``.
## Configuration file format
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 0c698305b9..1ae4796522 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -183,7 +183,7 @@ Description | URLs
-----|-----
Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
-Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
+Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 98998d7f74..d511360e22 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -1,6 +1,5 @@
---
title: Opening a pull request
-slug: new-content
content_type: concept
weight: 10
card:
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index e9ef332430..b1f7e4f20a 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
+- In addition to the standard Hugo shortcodes, we use a number of
+ [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+ language has its own folder with a two-letter code determined by the
+ [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
+ example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md
index a99eaf464e..a5c0f2880a 100644
--- a/content/en/docs/contribute/participate/_index.md
+++ b/content/en/docs/contribute/participate/_index.md
@@ -20,18 +20,18 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a
pull request (PR), and anyone is welcome to file issues about content or comment
on pull requests in progress.
-You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
-[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater
-access and entail certain responsibilities for approving and committing changes.
-See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members),
+[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or
+[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers).
+These roles require greater access and entail certain responsibilities for
+approving and committing changes. See
+[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for more information on how membership works within the Kubernetes community.
The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
-
-
## SIG Docs chairperson
@@ -58,8 +58,9 @@ There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/
Each can be referenced with their `@name` in GitHub comments to communicate with
everyone in that group.
-Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals,
-the automation uses information from `OWNERS` files.
+Sometimes Prow and GitHub teams overlap without matching exactly. For
+assignment of issues, pull requests, and to support PR approvals, the
+automation uses information from `OWNERS` files.
### OWNERS files and front-matter
@@ -114,6 +115,6 @@ SIG Docs approvers. Here's how it works.
For more information about contributing to the Kubernetes documentation, see:
-- [Contributing new content](/docs/contribute/overview/)
+- [Contributing new content](/docs/contribute/new-content/overview/)
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
index 6538e813df..c2ab60a811 100644
--- a/content/en/docs/contribute/participate/pr-wranglers.md
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -36,16 +36,16 @@ The following queries are helpful when wrangling.
After working through these queries, the remaining list of PRs to review is usually small.
These queries exclude localization PRs. All queries are against the main branch except the last one.
-- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
+- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
-- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
+- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
-- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
+- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
Lists PRs that need an `/approve` comment to merge.
-- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
-- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
### When to close Pull Requests
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md
new file mode 100644
index 0000000000..8ebe7a1303
--- /dev/null
+++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md
@@ -0,0 +1,237 @@
+---
+title: Roles and responsibilities
+content_type: concept
+weight: 10
+---
+
+
+
+Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow,
+you can apply for different levels of membership in the community.
+These roles allow you to take on more responsibility within the community.
+Each role requires more time and commitment. The roles are:
+
+- Anyone: regular contributors to the Kubernetes documentation
+- Members: can assign and triage issues and provide non-binding review on pull requests
+- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
+- Approvers: can lead reviews on documentation and merge changes
+
+
+
+## Anyone
+
+Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
+
+Anyone can:
+
+- Open an issue in any [Kubernetes](https://github.com/kubernetes/)
+ repository, including
+ [`kubernetes/website`](https://github.com/kubernetes/website)
+- Give non-binding feedback on a pull request
+- Contribute to a localization
+- Suggest improvements on [Slack](https://slack.k8s.io/) or the
+ [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
+
+- Open a pull request to improve existing content, add new content, or write a blog post or case study
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+
+For more information, see [contributing new content](/docs/contribute/new-content/).
+
+## Members
+
+A member is someone who has submitted multiple pull requests to
+`kubernetes/website`. Members are a part of the
+[Kubernetes GitHub organization](https://github.com/kubernetes).
+
+Members can:
+
+- Do everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
+
+ {{< note >}}
+ Using `/lgtm` triggers automation. If you want to provide non-binding
+ approval, simply commenting "LGTM" works too!
+ {{< /note >}}
+
+- Use the `/hold` comment to block merging for a pull request
+- Use the `/assign` comment to assign a reviewer to a pull request
+- Provide non-binding review on pull requests
+- Use automation to triage and categorize issues
+- Document new features
+
+### Becoming a member
+
+After submitting at least 5 substantial pull requests and meeting the other
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
+
+1. Find two [reviewers](#reviewers) or [approvers](#approvers) to
+ [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your
+ membership.
+
+ Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
+ [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+ {{< note >}}
+ Don't send a direct email or Slack direct message to an individual
+ SIG Docs member. You must request sponsorship before submitting your application.
+ {{< /note >}}
+
+1. Open a GitHub issue in the
+ [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the
+ **Organization Membership Request** issue template.
+
+1. Let your sponsors know about the GitHub issue. You can either:
+ - Mention their GitHub username in an issue (`@`)
+ - Send them the issue link using Slack or email.
+
+ Sponsors will approve your request with a `+1` vote. Once your sponsors
+ approve the request, a Kubernetes GitHub admin adds you as a member.
+ Congratulations!
+
+ If your membership request is not accepted you will receive feedback.
+ After addressing the feedback, apply again.
+
+1. Accept the invitation to the Kubernetes GitHub organization in your email account.
+
+ {{< note >}}
+ GitHub sends the invitation to the default email address in your account.
+ {{< /note >}}
+
+## Reviewers
+
+Reviewers are responsible for reviewing open pull requests. Unlike member
+feedback, you must address reviewer feedback. Reviewers are members of the
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub team.
+
+Reviewers can:
+
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Review pull requests and provide binding feedback
+
+ {{< note >}}
+ To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
+ {{< /note >}}
+
+- Edit user-facing strings in code
+- Improve code comments
+
+You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
+
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
+review from a specific person by commenting: `/assign
+[@_github_handle]`.
+
+If the assigned reviewer has not commented on the PR, another reviewer can
+step in. You can also assign technical reviewers as needed.
+
+### Using `/lgtm`
+
+LGTM stands for "Looks good to me" and indicates that a pull request is
+technically accurate and ready to merge. All PRs need a `/lgtm` comment from a
+reviewer and a `/approve` comment from an approver to merge.
+
+A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
+
+### Becoming a reviewer
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
+you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
+separately for reviewer status in SIG Docs.
+
+To apply:
+
+1. Open a pull request that adds your GitHub user name to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
+ in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
+ {{< /note >}}
+
+1. Assign the PR to one or more SIG-Docs approvers (user names listed under
+ `sig-docs-{language}-owners`).
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## Approvers
+
+Approvers review and approve pull requests for merging. Approvers are members of the
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub teams.
+
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling
+
+If the PR already has a `/lgtm`, or if the approver also comments with
+`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a
+`/lgtm` on a change that doesn't need additional technical review.
+
+
+### Approving pull requests
+
+Approvers and SIG Docs leads are the only ones who can merge pull requests
+into the website repository. This comes with certain responsibilities.
+
+- Approvers can use the `/approve` command, which merges PRs into the repo.
+
+ {{< warning >}}
+ A careless merge can break the site, so be sure that when you merge something, you mean it.
+ {{< /warning >}}
+
+- Make sure that proposed changes meet the
+ [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
+
+ If you ever have a question, or you're not sure about something, feel free
+ to call for additional review.
+
+- Verify that Netlify tests pass before you `/approve` a PR.
+
+
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md
deleted file mode 100644
index f4cca67155..0000000000
--- a/content/en/docs/contribute/participate/roles-and-responsibilties.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Roles and responsibilities
-content_type: concept
-weight: 10
----
-
-
-
-Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
-These roles allow you to take on more responsibility within the community.
-Each role requires more time and commitment. The roles are:
-
-- Anyone: regular contributors to the Kubernetes documentation
-- Members: can assign and triage issues and provide non-binding review on pull requests
-- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
-- Approvers: can lead reviews on documentation and merge changes
-
-
-
-## Anyone
-
-Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
-
-Anyone can:
-
-- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
-- Give non-binding feedback on a pull request
-- Contribute to a localization
-- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-
-- Open a pull request to improve existing content, add new content, or write a blog post or case study
-- Create diagrams, graphics assets, and embeddable screencasts and videos
-
-For more information, see [contributing new content](/docs/contribute/new-content/).
-
-## Members
-
-A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
-
-Members can:
-
-- Do everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
-
- {{< note >}}
- Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
- {{< /note >}}
-- Use the `/hold` comment to block merging for a pull request
-- Use the `/assign` comment to assign a reviewer to a pull request
-- Provide non-binding review on pull requests
-- Use automation to triage and categorize issues
-- Document new features
-
-### Becoming a member
-
-After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
-
-1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
-
- Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member. You must request sponsorship before submitting your application.
- {{< /note >}}
-
-2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-
-3. Let your sponsors know about the GitHub issue. You can either:
- - Mention their GitHub username in an issue (`@`)
- - Send them the issue link using Slack or email.
-
- Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
-
- If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
-
-4. Accept the invitation to the Kubernetes GitHub organization in your email account.
-
- {{< note >}}
- GitHub sends the invitation to the default email address in your account.
- {{< /note >}}
-
-## Reviewers
-
-Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
-
-Reviewers can:
-
-- Do everything listed under [Anyone](#anyone) and [Members](#members)
-- Review pull requests and provide binding feedback
-
- {{< note >}}
- To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
- {{< /note >}}
-
-- Edit user-facing strings in code
-- Improve code comments
-
-You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
-
-### Assigning reviewers to pull requests
-
-Automation assigns reviewers to all pull requests. You can request a
-review from a specific person by commenting: `/assign
-[@_github_handle]`.
-
-If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
-
-### Using `/lgtm`
-
-LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
-
-A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
-
-### Becoming a reviewer
-
-When you meet the
-[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs.
-
-To apply:
-
-1. Open a pull request that adds your GitHub user name to a section of the
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
-in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
- {{< /note >}}
-
-2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## Approvers
-
-Approvers review and approve pull requests for merging. Approvers are members of the
-[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
-
-Approvers can do the following:
-
-- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
-- Publish contributor content by approving and merging pull requests using the `/approve` comment
-- Propose improvements to the style guide
-- Propose improvements to docs tests
-- Propose improvements to the Kubernetes website or other tooling
-
-If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review.
-
-
-### Approving pull requests
-
-Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
-
-- Approvers can use the `/approve` command, which merges PRs into the repo.
-
- {{< warning >}}
- A careless merge can break the site, so be sure that when you merge something, you mean it.
- {{< /warning >}}
-
-- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
-
- If you ever have a question, or you're not sure about something, feel free to call for additional review.
-
-- Verify that Netlify tests pass before you `/approve` a PR.
-
-
-
-- Visit the Netlify page preview for a PR to make sure things look good before approving.
-
-- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/).
-for more details.
-
-### Becoming an approver
-
-When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
-
-To apply:
-
-1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
- {{< /note >}}
-
-2. Assign the PR to one or more current SIG Docs approvers.
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## {{% heading "whatsnext" %}}
-
-- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
\ No newline at end of file
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 0cddbcba6a..82a05bdb86 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -8,7 +8,9 @@ weight: 20
-SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
+SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
+[Approvers](/docs/contribute/participate/#approvers) do a few extra things
+when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -19,9 +21,6 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-
-
-
## Reviewing a PR
@@ -202,9 +201,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
-[Kubernetes slack](http://slack.k8s.io/). You can also search
+[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index 3c271aa44f..ff6ef9d709 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
-[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-
-
+ [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Understand the different
+ [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/)
+ in the Kubernetes documentation community.
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index 569ca8d72c..0de4a381a3 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -10,9 +10,9 @@ weight: 10
This page contains guidelines for Kubernetes documentation.
If you have questions about what's allowed, join the #sig-docs channel in
-[Kubernetes Slack](http://slack.k8s.io/) and ask!
+[Kubernetes Slack](https://slack.k8s.io/) and ask!
-You can register for Kubernetes Slack at http://slack.k8s.io/.
+You can register for Kubernetes Slack at https://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
@@ -67,7 +67,7 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes
### More information
-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
+If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index e4a6d703ad..ab949be7fc 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -232,7 +232,7 @@ Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
-{{< tab name="JSON File" include="podtemplate" />}}
+{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
@@ -242,6 +242,6 @@ Renders to:
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/contribute/style/page-content-types/).
-* Learn about [creating a pull request](/docs/contribute/new-content/new-content/).
+* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
index 2a3325d397..5d3b519bc0 100644
--- a/content/en/docs/contribute/style/page-content-types.md
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines:
interested in reading next.
An example of a published tutorial topic is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
### Reference
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 55aa30d66c..44653708ec 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -22,8 +22,11 @@ discussion.
{{< note >}}
-Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
-and representing feature state.
+Kubernetes documentation uses
+[Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
+with some adjustments along with a few
+[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support
+glossary entries, tabs, and representing feature state.
{{< /note >}}
## Language
@@ -584,12 +587,8 @@ The Federation feature provides ... | The new Federation feature provides ...
{{< /table >}}
-
-
## {{% heading "whatsnext" %}}
-
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [using page templates](/docs/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 3e4f999c08..7cac1aa6b7 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs.
## {{% heading "prerequisites" %}}
Create a fork of the Kubernetes documentation repository as described in
-[Open a PR](/docs/new-content/open-a-pr/).
+[Open a PR](/docs/contribute/new-content/open-a-pr/).
@@ -160,7 +160,7 @@ submitted to ensure all examples pass the tests.
{{< /note >}}
For an example of a topic that uses this technique, see
-[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
+[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/).
## Adding images to a topic
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index c0747f3d56..7e1f8ced66 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -677,9 +677,6 @@ for more information.
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
for more information.
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index d196be938d..398f06b671 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 1227f750eb..a9db3b00eb 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -997,7 +997,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
### Matching requests: matchPolicy
API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 20b1224e59..2be833826c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation.
Kubernetes RBAC API discovery roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:basic-user
system:authenticated group
@@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation.
system:authenticated and system:unauthenticated groups
Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
+
### User-facing roles
@@ -649,12 +653,15 @@ metadata:
```
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
cluster-admin
system:masters group
@@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials
in the namespace, which would allow API access as any ServiceAccount
in the namespace (a form of privilege escalation).
+
### Core component roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:kube-scheduler
system:kube-scheduler user
@@ -733,17 +744,21 @@ The system:node role only exists for compatibility with Kubernetes clus
system:kube-proxy user
Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+
### Other component roles
-
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:auth-delegator
None
@@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho
None
Allows access to the resources required by most dynamic volume provisioners.
+
### Roles for built-in controllers {#controller-roles}
diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md
index f14393072c..b551dead19 100755
--- a/content/en/docs/reference/glossary/pod.md
+++ b/content/en/docs/reference/glossary/pod.md
@@ -2,7 +2,7 @@
title: Pod
id: pod
date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /docs/concepts/workloads/pods/
short_description: >
A Pod represents a set of running containers in your cluster.
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 25b7d46af9..c0adee3bdb 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API.
To eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
The version is set at the API level rather than at the resource or field level to:
@@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve
to pick up the `--runtime-config` changes.
{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
new file mode 100644
index 0000000000..a7be3b267f
--- /dev/null
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -0,0 +1,103 @@
+---
+title: Kubernetes API health endpoints
+reviewers:
+- logicalhan
+content_type: concept
+weight: 50
+---
+
+
+The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
+This page describes these API endpoints and explains how you can use them.
+
+
+
+## API endpoints for health
+
+The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
+The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
+The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
+For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
+Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
+A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
+
+The following examples will show how you can interact with the health API endpoints.
+
+For all endpoints you can use the `verbose` parameter to print out the checks and their status.
+This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+
+ ```shell
+ curl -k https://localhost:6443/livez?verbose
+ ```
+
+or from a remote host with authentication:
+
+ ```shell
+ kubectl get --raw='/readyz?verbose'
+ ```
+
+The output will look like this:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ healthz check passed
+
+The Kubernetes API server also supports to exclude specific checks.
+The query parameters can also be combined like in this example:
+
+ ```shell
+ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+ ```
+
+The output show that the `etcd` check is excluded:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd excluded: ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ [+]shutdown ok
+ healthz check passed
+
+## Individual health checks
+
+{{< feature-state state="alpha" >}}
+
+Each individual health check exposes an http endpoint and could can be checked individually.
+The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server.
+The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
+These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
+
+ ```shell
+ curl -k https://localhost:6443/livez/etcd
+ ```
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index c8692c8872..2b8f7b487f 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
@@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
### Addon Resources
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
For example:
@@ -94,28 +94,26 @@ For example:
memory: 200Mi
```
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
- * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
- * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
- * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+ * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+ * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+ * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
- * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+ * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
- * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
- * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+ * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+ * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
### Allowing minor node failure at startup
@@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh
with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
reason for the failure, those additional nodes may join later or the cluster may remain at a size of
`NUM_NODES - ALLOWED_NOTREADY_NODES`.
+
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index ab61c839a9..7c2622641b 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -78,7 +78,7 @@ federation support).
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
### Volume limitations
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
index a794141f2d..009be9adc8 100644
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ b/content/en/docs/setup/learning-environment/minikube.md
@@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo
The `minikube start` command can be used to start your cluster.
This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
+This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster.
{{< note >}}
If you are behind a web proxy, you need to pass this information to the `minikube start` command:
@@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
## Community
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
index 1f7d1fd81f..c440f14b31 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
@@ -9,12 +9,10 @@ content_type: concept
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-
-
## Prerequisites
@@ -112,10 +110,7 @@ e9af8293... role=node
## Support Level
-
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md
index 7cbeccf7cb..8394c28faf 100644
--- a/content/en/docs/setup/production-environment/tools/kops.md
+++ b/content/en/docs/setup/production-environment/tools/kops.md
@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
but not under `example.com`).
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
@@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
## {{% heading "whatsnext" %}}
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index aa9245ea65..82184f7784 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -8,7 +8,7 @@ weight: 30
-The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
-(CNI) based Pod network add-on so that your Pods can communicate with each other.
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
- networks: you are likely to see problems if there is any overlap.
+ networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
@@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
- control).
+ control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
- supports IPv6.
+ supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
{{< /caution >}}
@@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers.
{{< /note >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
-See the list of available
-[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
@@ -297,79 +297,6 @@ kubectl apply -f
```
You can install only one Pod network per cluster.
-Below you can find installation instructions for some popular Pod network plugins:
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
-
-Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-
-To deploy Cilium you just need to run:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
-```
-
-Once all Cilium Pods are marked as `READY`, you start using your cluster.
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-The output is similar to this:
-```
-NAME READY STATUS RESTARTS AGE
-cilium-drxkl 1/1 Running 0 18m
-```
-
-Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
-
-For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
-
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
-offering feature-rich & high-performance cloud-native networking and services.
-
-It implements k8s services and network policies in the user space (on VPP).
-
-Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
-
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
-
-For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-
-For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/).
-
-Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
-Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
-if they don't know their PodIP.
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-{{% /tab %}}
-
-{{< /tabs >}}
-
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
@@ -578,9 +505,9 @@ options.
* See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
for details about upgrading your cluster using `kubeadm`.
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
-of Pod network add-ons.
+ of Pod network add-ons.
* See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
explore other add-ons, including tools for logging, monitoring, network policy, visualization &
control of your Kubernetes cluster.
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 5584309406..e91e9f7a60 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool
If you encounter issues with setting up the HA cluster, please provide us with feedback
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
-See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
{{< caution >}}
This page does not address running your cluster on a cloud provider. In a cloud
@@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
-
-
## {{% heading "prerequisites" %}}
@@ -51,8 +49,6 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-
-
## First steps for both methods
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 334e2266f2..d860a88bdd 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -13,14 +13,12 @@ weight: 100
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/)
configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-
-
#### Caveats
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index a4d6d54cc2..696778f974 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
+- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`,
+ or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-
-
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 64ad3f4b1a..02d99d926a 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -8,7 +8,7 @@ weight: 30
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
* composable attributes
@@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* openSUSE Leap 15
* continuous integration tests
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-
-
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
@@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment:
### (2/5) Compose an inventory file
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
@@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* {{< glossary_tooltip term_id="cri-o" >}}
* Certificate generation methods
-Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
### (4/5) Deploy a Cluster
@@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
index cbfccd7a56..be75623158 100644
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ b/content/en/docs/setup/production-environment/turnkey/aws.md
@@ -48,7 +48,7 @@ export PATH=/platforms/darwin/amd64:$PATH
export PATH=/platforms/linux/amd64:$PATH
```
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
+An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
@@ -63,7 +63,8 @@ For more complete applications, please look in the [examples directory](https://
## Scaling the cluster
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
+Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
+[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
## Tearing down the cluster
@@ -80,13 +81,8 @@ cluster/kube-down.sh
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
-AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
-AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
+AWS | CoreOS | CoreOS | flannel | - | | Community
+AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
index 60c4e690d9..3ea666eb7c 100644
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ b/content/en/docs/setup/production-environment/turnkey/gce.md
@@ -72,7 +72,7 @@ cluster/kube-up.sh
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
The next few steps will show you:
@@ -85,7 +85,7 @@ The next few steps will show you:
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
manager. It lets you inspect your cluster resources, create, delete, and update
components, and much more. You will use it to look at your new cluster and bring
up example apps.
@@ -98,7 +98,7 @@ gcloud components install kubectl
{{< note >}}
The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
document to see how you can set up the latest `kubectl` on your workstation.
{{< /note >}}
@@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
kubectl get --all-namespaces services
```
-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
```shell
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
@@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3
...
```
-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
You can do this via the
```shell
@@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
### Run some examples
-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
@@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index b0c5f1596d..812d86faf7 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications
## Windows containers in Kubernetes
-To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
+To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
@@ -65,7 +65,7 @@ From an API and kubectl perspective, Windows containers behave in much the same
Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
-* [Pods](/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/docs/concepts/workloads/pods/)
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index 6a115f72cc..310127f838 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
## Supported versions
Kubernetes versions are expressed as **x.y.z**,
-where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
+where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 9288ec3064..a0c68ff682 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Create `example-ingress.yaml` from the following file:
- apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
+ apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-ingress
@@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via
Output:
```shell
- ingress.extensions/example-ingress configured
+ ingress.networking/example-ingress configured
```
## Test Your Ingress
diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
index fe90981432..1194288386 100644
--- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment:
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has two
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has two
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
+
1. Display information about the Deployment:
```shell
kubectl get deployments hello-world
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 729c7bde4f..be7cbf2673 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -19,15 +19,15 @@ PersistentVolume.
## Why change reclaim policy of a PersistentVolume
-`PersistentVolumes` can have various reclaim policies, including "Retain",
-"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
+PersistentVolumes can have various reclaim policies, including "Retain",
+"Recycle", and "Delete". For dynamically provisioned PersistentVolumes,
the default reclaim policy is "Delete". This means that a dynamically provisioned
volume is automatically deleted when a user deletes the corresponding
-`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume
+PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
contains precious data. In that case, it is more appropriate to use the "Retain"
-policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
-the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
-`Released` phase, where all of its data can be manually recovered.
+policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
+the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
+Released phase, where all of its data can be manually recovered.
## Changing the reclaim policy of a PersistentVolume
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 6fd887bd8f..f333b215a2 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
The output is:
- deployment.extensions/dns-autoscaler scaled
+ deployment.apps/dns-autoscaler scaled
Verify that the replica count is zero:
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e82c53f3a6..c3498fce61 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### Joining a Windows worker node
{{< note >}}
You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
{{< /note >}}
{{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
index b4b7afd6de..1d1461ade7 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
This example assumes the following:
1. You have an [existing Kubernetes cluster](/docs/setup/).
-2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
## Understand the default namespace
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index 1b47b14188..00dec41774 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
## {{% heading "prerequisites" %}}
* Have an [existing Kubernetes cluster](/docs/setup/).
-* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index e18b2ed87d..ed1b9657c8 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites:
You can use `kubectl drain` to safely evict all of your pods from a
node before you perform maintenance on the node (e.g. kernel upgrade,
hardware maintenance, etc.). Safe evictions allow the pod's containers
-to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
and will respect the `PodDisruptionBudgets` you have specified.
{{< note >}}
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index f5116e7691..00b9251be8 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes.
Kubernetes sends the preStop event immediately before the Container is terminated.
Kubernetes' management of the Container blocks until the preStop handler completes,
unless the Pod's grace period expires. For more details, see
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
{{< note >}}
Kubernetes only sends the preStop event when a Pod is *terminated*.
diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md
index 5189fdb882..cf31d822d6 100644
--- a/content/en/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/static-pod.md
@@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Unlike Pods that are managed by the control plane (for example, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}});
-instead, the kubelet watches each static Pod (and restarts it if it crashes).
+instead, the kubelet watches each static Pod (and restarts it if it fails).
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index f64a55bd29..aad8aac2ee 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -133,6 +133,40 @@ log audit backend using the following `kube-apiserver` flags:
- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example,
+`
+--audit-policy-file=/etc/kubernetes/audit-policy.yaml
+--audit-log-path=/var/log/audit.log
+`
+then mount the volumes:
+
+
+```
+volumeMounts:
+ - mountPath: /etc/kubernetes/audit-policy.yaml
+ name: audit
+ readOnly: true
+ - mountPath: /var/log/audit.log
+ name: audit-log
+ readOnly: false
+```
+finally the hostPath:
+
+```
+- name: audit
+ hostPath:
+ path: /etc/kubernetes/audit-policy.yaml
+ type: File
+
+- name: audit-log
+ hostPath:
+ path: /var/log/audit.log
+ type: FileOrCreate
+
+```
+
+
+
### Webhook backend
Webhook backend sends audit events to a remote API, which is assumed to be the
@@ -206,7 +240,7 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
If you're extending the Kubernetes API with the [aggregation
layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/),
-y ou can also set up audit logging for the aggregated apiserver. To do this,
+you can also set up audit logging for the aggregated apiserver. To do this,
pass the configuration options in the same format as described above to the
aggregated apiserver and set up the log ingesting pipeline to pick up audit
logs. Different apiservers can have different audit configurations and
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index a5c37541c3..edd23c35e7 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -118,7 +118,7 @@ You can view this resource with:
kubectl get endpoints ${SERVICE_NAME}
```
-Make sure that the endpoints match up with the number of containers that you expect to be a member of your service.
+Make sure that the endpoints match up with the number of pods that you expect to be members of your service.
For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different
IP addresses in the Service's endpoints.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 9793b472e0..8fb5bffd37 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
- [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and with
+ Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md
deleted file mode 100644
index 634b9d33c1..0000000000
--- a/content/en/docs/tasks/debug-application-cluster/falco.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: Auditing with Falco
----
-
-
-### Use Falco to collect audit events
-
-[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
-This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
-
-
-
-#### Install Falco
-
-Install Falco by using one of the following methods:
-
-- [Standalone Falco](https://falco.org/docs/installation)
-- [Kubernetes DaemonSet](https://falco.org/docs/installation)
-- [Falco Helm Chart](https://github.com/falcosecurity/charts/tree/master/falco)
-
-Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
-
-```yaml
-webserver:
- enabled: true
- listen_port: 8765
- k8s_audit_endpoint: /k8s_audit
- ssl_enabled: false
- ssl_certificate: /etc/falco/falco.pem
-```
-
-This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
-
-#### Configure Kubernetes Audit
-
-1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
- for the [kube-apiserver](/docs/reference/generated/kube-apiserver/) webhook audit backend.
-
- cat < /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
-
-1. Start `kube-apiserver` with the following options:
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
-
-#### Audit Rules
-
-Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml](https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml).
-If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
-
-There are three classes of rules.
-
-The first class of rules looks for suspicious or exceptional activities, such as:
-
-- Any activity by an unauthorized or anonymous user.
-- Creating a pod with an unknown or disallowed image.
-- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
-- Creating a NodePort service.
-- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
-- Attaching to or executing a command on a running pod.
-- Creating a namespace external to a set of allowed namespaces.
-- Creating a pod or service account in the kube-system or kube-public namespaces.
-- Trying to modify or delete a system ClusterRole.
-- Creating a ClusterRoleBinding to the cluster-admin role.
-- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
-- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
-
-A second class of rules tracks resources being created or destroyed, including:
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
-
-The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
-
-For further details, see [Kubernetes Audit Events](https://falco.org/docs/event-sources/kubernetes-audit) in the Falco documentation.
-
-
diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 4afbee21c8..b14777111e 100644
--- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -129,45 +129,8 @@ If RBAC is enabled on your cluster, you must update the `system:kube-scheduler`
```
kubectl edit clusterrole system:kube-scheduler
```
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- annotations:
- rbac.authorization.kubernetes.io/autoupdate: "true"
- labels:
- kubernetes.io/bootstrapping: rbac-defaults
- name: system:kube-scheduler
-rules:
-- apiGroups:
- - coordination.k8s.io
- resources:
- - leases
- verbs:
- - create
-- apiGroups:
- - coordination.k8s.io
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - leases
- verbs:
- - get
- - update
-- apiGroups:
- - ""
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - endpoints
- verbs:
- - delete
- - get
- - patch
- - update
-```
+
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
## Specify schedulers for pods
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index 7a4a94fab4..57e54e6797 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp
### Persistent Volumes
-Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
{{< note >}}
Use caution when deleting a PVC, as it may lead to data loss.
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 48a61a260d..e706c6179a 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods
```
-For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver.
+For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 7f3b046b68..6806ba0dc0 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -47,7 +47,7 @@ The Dockerfile has the following content:
```
FROM php:5-apache
-ADD index.php /var/www/html/index.php
+COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index cabf9a3c7b..7f43d34be7 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -2,5 +2,40 @@
title: "Install Tools"
description: Set up Kubernetes tools on your computer.
weight: 10
+no_list: true
---
+## kubectl
+
+The Kubernetes command-line tool, `kubectl`, allows you to run commands against
+Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
+cluster resources, and view logs.
+
+See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
+download and install `kubectl` and set it up for accessing your cluster.
+
+You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
+Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
+or for daily development work.
+
+You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
+guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
+is on getting the tool installed.
+
+Once you have Minikube working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+
+## kind
+
+Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local compute. Unlike Minikuke, kind only works with a single container runtime:
+it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
+and configured.
+
+[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
+need to do to get up and running with kind.
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 25b5cab9b5..22b960751f 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -28,7 +28,7 @@ You must use a kubectl version that is within one minor version difference of yo
1. Download the latest release with the command:
```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 9ba2de1abf..f0aa44369e 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re
## Create a Deployment
-A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
+A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 6d7e15a7c4..fb782458de 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
- A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
+ A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 8a7d60dd87..c610b6e9f4 100644
--- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
Overview of Kubernetes Services
- Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
+ Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md
index 2e8710b758..d04902ddfe 100644
--- a/content/en/docs/tutorials/services/source-ip.md
+++ b/content/en/docs/tutorials/services/source-ip.md
@@ -1,6 +1,7 @@
---
title: Using Source IP
content_type: tutorial
+mermaid: true
min-kubernetes-server-version: v1.5
---
@@ -177,7 +178,7 @@ service/nodeport exposed
```shell
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
-NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
+NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
```
If you're running on a cloud provider, you may need to open up a firewall-rule
@@ -206,18 +207,19 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th
Visually:
-```
- client
- \ ^
- \ \
- v \
- node 1 <--- node 2
- | ^ SNAT
- | | --->
- v |
- endpoint
-```
+{{< mermaid >}}
+graph LR;
+ client(client)-->node2[Node 2];
+ node2-->client;
+ node2-. SNAT .->node1[Node 1];
+ node1-. SNAT .->node2;
+ node1-->endpoint(Endpoint);
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{}}
To avoid this, Kubernetes has a feature to
[preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip).
@@ -261,17 +263,18 @@ This is what happens:
Visually:
-```
- client
- ^ / \
- / / \
- / v X
- node 1 node 2
- ^ |
- | |
- | v
- endpoint
-```
+{{< mermaid >}}
+graph TD;
+ client --> node1[Node 1];
+ client(client) --x node2[Node 2];
+ node1 --> endpoint(endpoint);
+ endpoint --> node1;
+
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{}}
@@ -324,17 +327,7 @@ deliberately failing health checks.
Visually:
-```
- client
- |
- lb VIP
- / ^
- v /
-health check ---> node 1 node 2 <--- health check
- 200 <--- ^ | ---> 500
- | V
- endpoint
-```
+
You can test this by setting the annotation:
diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
index 2974c77c94..5babc2c0b0 100644
--- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has five
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has five
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
1. Display information about the Deployment:
diff --git a/content/en/examples/admin/sched/clusterrole.yaml b/content/en/examples/admin/sched/clusterrole.yaml
new file mode 100644
index 0000000000..554b8659db
--- /dev/null
+++ b/content/en/examples/admin/sched/clusterrole.yaml
@@ -0,0 +1,37 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ annotations:
+ rbac.authorization.kubernetes.io/autoupdate: "true"
+ labels:
+ kubernetes.io/bootstrapping: rbac-defaults
+ name: system:kube-scheduler
+rules:
+ - apiGroups:
+ - coordination.k8s.io
+ resources:
+ - leases
+ verbs:
+ - create
+ - apiGroups:
+ - coordination.k8s.io
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - leases
+ verbs:
+ - get
+ - update
+ - apiGroups:
+ - ""
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - endpoints
+ verbs:
+ - delete
+ - get
+ - patch
+ - update
diff --git a/content/es/_index.html b/content/es/_index.html
index cf19b195cd..8aecd07aaf 100644
--- a/content/es/_index.html
+++ b/content/es/_index.html
@@ -4,8 +4,6 @@ abstract: "Automatización del despliegue, escalado y administración de contene
cid: home
---
-{{< deprecationwarning >}}
-
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
### Kubernetes (K8s) es una plataforma de código abierto para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores.
@@ -57,4 +55,4 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr
{{< /blocks/section >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..b607f0b82d
--- /dev/null
+++ b/content/es/docs/concepts/configuration/configmap.md
@@ -0,0 +1,253 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+
+
+{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}}
+
+{{< caution >}}
+ConfigMap no proporciona encriptación.
+Si los datos que quieres almacenar son confidenciales, utiliza un
+{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap,
+o utiliza otras herramientas externas para mantener los datos seguros.
+{{< /caution >}}
+
+
+
+
+## Motivo
+
+Utiliza un ConfigMap para crear una configuración separada del código de la aplicación.
+
+Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en
+tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real).
+Escribes el código para configurar una variable llamada `DATABASE_HOST`.
+En tu equipo configuras la variable con el valor `localhost`.
+En el cloud, la configuras con referencia a un kubernetes
+{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente
+de la base de datos en tu cluster.
+
+Esto permite tener una imagen corriendo en un cloud y
+tener el mismo código localmente para checkearlo si es necesario.
+
+## Objeto ConfigMap
+
+Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API
+que permite almacenar la configuración de otros objetos utilizados. Aunque muchos
+objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para
+almacenar items, identificados por una clave, y sus valores.
+
+El nombre del ConfigMap debe ser un
+[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
+
+## ConfigMaps y Pods
+
+Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es)
+de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en
+el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+
+Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple,
+y otras claves donde el valor tiene un formato de un fragmento de configuración.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # property-like keys; each key maps to a simple value
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+ #
+ # file-like keys
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+Hay cuatro maneras diferentes de usar un ConfigMap para configurar
+un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Argumento en la linea de comandos como entrypoint de un contenedor
+1. Variable de enorno de un contenedor
+1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación
+1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap
+
+Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar
+los datos que se van a usar.
+Para los primeros tres mecanismos, el
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información
+del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+
+Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos.
+Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede
+suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar
+cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta
+técnica también permite acceder al ConfigMap en diferentes namespaces.
+
+En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: game.example/demo-game
+ env:
+ # Define the environment variable
+ - name: PLAYER_INITIAL_LIVES # Notice that the case is different here
+ # from the key name in the ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # The ConfigMap this value comes from.
+ key: player_initial_lives # The key to fetch.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # You set volumes at the Pod level, then mount them into containers inside that Pod
+ - name: config
+ configMap:
+ # Provide the name of the ConfigMap you want to mount.
+ name: game-demo
+ # An array of keys from the ConfigMap to create as files
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+
+Un ConfigMap no diferencia entre las propiedades de una linea individual y
+un fichero con múltiples lineas y valores.
+Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores.
+
+Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor
+`demo` como `/config` creando dos ficheros,
+`/config/game.properties` y `/config/user-interface.properties`,
+aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición
+del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`.
+Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en
+un fichero con el mismo nombre que la clave, y tienes 4 ficheros.
+
+## Usando ConfigMaps
+
+Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras
+partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo,
+los ConfigMaps pueden contener información para que otros elementos del sistema utilicen
+para su configuración.
+
+{{< note >}}
+La manera más común de usar los Configmaps es para configurar
+los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+También se pueden usar por separado.
+
+Por ejemplo,
+quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}}
+u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que
+ajustan su comportamiento en base a un ConfigMap.
+{{< /note >}}
+
+### Usando ConfigMaps como ficheros en un Pod
+
+Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap.
+1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap.
+1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap.
+1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`.
+
+En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`.
+
+Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio
+bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap.
+
+#### ConfigMaps montados son actualizados automáticamente
+
+Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también.
+El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización.
+Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap.
+El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo
+todas las consultas directamente a la API.
+Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento
+que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}}
++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de
+caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar
+{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión
+(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus
+datos con las siguientes ventajas:
+
+- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones
+- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}},
+cerrando las vistas para el ConfigMap marcado como inmutable.
+
+Para usar esta característica, habilita el `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura
+el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio
+ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap.
+Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable
+recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+{{< /note >}}
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Leer sobre [Secrets](/docs/concepts/configuration/secret/).
+* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar
+ el código de la configuración.
diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..577e24dc1f
--- /dev/null
+++ b/content/es/docs/reference/glossary/configmap.md
@@ -0,0 +1,18 @@
+---
+title: Configmap
+id: configmap
+date: 2020-07-11
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+ Almacena información no sensible.
+
+aka:
+tags:
+- workload
+---
+Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}.
+
+Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables.
+
+
+
diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md
index 8d60357aea..2a88388374 100644
--- a/content/fr/docs/tasks/tools/install-kubectl.md
+++ b/content/fr/docs/tasks/tools/install-kubectl.md
@@ -121,7 +121,7 @@ kubectl version --client
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
-2. Rendrez le binaire kubectl exécutable.
+2. Rendez le binaire kubectl exécutable.
```
chmod +x ./kubectl
diff --git a/content/id/_index.html b/content/id/_index.html
index 47d7f71ced..e95d661b76 100644
--- a/content/id/_index.html
+++ b/content/id/_index.html
@@ -4,7 +4,6 @@ abstract: "Otomatisasi Kontainer deployment, scaling, dan management"
cid: home
---
-{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
@@ -60,4 +59,4 @@ Kubernetes sebagai open source memberikan kamu kebebasan untuk menggunaka
{{< blocks/kubernetes-features >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md
index ebc205d84a..33f4ada445 100644
--- a/content/id/docs/concepts/_index.md
+++ b/content/id/docs/concepts/_index.md
@@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail.
Objek mendasar Kubernetes termasuk:
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
+* [Pod](/id/docs/concepts/workloads/pods/pod-overview/)
+* [Service](/id/docs/concepts/services-networking/service/)
+* [Volume](/id/docs/concepts/storage/volumes/)
+* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/)
Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler.
Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
+* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/)
## *Control Plane* Kubernetes
@@ -95,7 +95,7 @@ dengan *node* secara langsung.
#### Metadata objek
-* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/)
+* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/)
diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md
index a0ff6b9256..6cf90cf9e6 100644
--- a/content/id/docs/concepts/architecture/controller.md
+++ b/content/id/docs/concepts/architecture/controller.md
@@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan.
Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari
Kubernetes.
-[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
+[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau
lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat
keadaan sekarang mendekati keadaan yang diinginkan.
@@ -174,6 +174,6 @@ khusus itu lakukan.
* Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane)
* Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects)
-* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
-* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
+* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/)
+* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md
index 8913c9df65..ab13cf122a 100644
--- a/content/id/docs/concepts/architecture/nodes.md
+++ b/content/id/docs/concepts/architecture/nodes.md
@@ -8,8 +8,8 @@ weight: 10
Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya.
-Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
-Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
+Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
+Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node).
@@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk
Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali.
Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan.
-Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
+Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual.
Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.
-Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
+Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod.
Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel.
@@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node.
## Manajemen
-Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
+Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat.
Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak.
Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
@@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m
Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints.
Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`.
-Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
+Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition.
Ini merupakan fitur alpha untuk versi 1.8.
@@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak
Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node.
Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node.
-Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
+Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md
index b404465d8f..ca50347492 100644
--- a/content/id/docs/concepts/cluster-administration/addons.md
+++ b/content/id/docs/concepts/cluster-administration/addons.md
@@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
* [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan.
-* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal.
## _Service Discovery_
diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md
index a605a78547..ee1f91cbeb 100644
--- a/content/id/docs/concepts/cluster-administration/certificates.md
+++ b/content/id/docs/concepts/cluster-administration/certificates.md
@@ -245,6 +245,6 @@ done.
Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan
sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan
-[di sini](/docs/tasks/tls/managing-tls-in-a-cluster).
+[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster).
diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md
index 45820e3660..9a32af1eb8 100644
--- a/content/id/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md
@@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan
Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node.
### *Load Balancer*
-Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
+Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
```yaml
apiVersion: v1
diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
index b485b5e142..b2bd349908 100644
--- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent
Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan:
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
- - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
+ - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/).
- Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**?
- Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster.
- - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai.
+ - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai.
- Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**?
- Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster.
@@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
* Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/).
-* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
+* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
## Mengamankan Klaster
-* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
+* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
-* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
+* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
* [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*.
@@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
## Layanan Tambahan Klaster
-* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
+* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
-* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
+* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md
index 7690a75a82..d59da126ad 100644
--- a/content/id/docs/concepts/cluster-administration/federation.md
+++ b/content/id/docs/concepts/cluster-administration/federation.md
@@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
-* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
+* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/)
[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
index 53203777f2..75f3b97189 100644
--- a/content/id/docs/concepts/cluster-administration/logging.md
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna
{{< /note >}}
Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
-yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
+yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md
index 81c0ba4d08..d67da9c13e 100644
--- a/content/id/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md
@@ -6,7 +6,7 @@ weight: 40
-Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/).
+Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/).
@@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`).
-Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
+Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
## Memperbarui anotasi
@@ -309,7 +309,7 @@ metadata:
...
```
-Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
+Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
## Memperbesar dan memperkecil aplikasi kamu
@@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image
kubectl edit deployment/my-nginx
```
-Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/).
+Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/).
@@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang
- [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/)
+- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/)
diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md
index 038465bcb8..6bcd78d7ef 100644
--- a/content/id/docs/concepts/cluster-administration/networking.md
+++ b/content/id/docs/concepts/cluster-administration/networking.md
@@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja.
Ada 4 masalah yang berbeda untuk diatasi:
1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh
- [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
+ [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
-3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
-4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
+3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
+4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
@@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus
### Romana
-[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
+[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
### Weave Net dari Weaveworks
diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md
index 5595414aa9..f3567233e0 100644
--- a/content/id/docs/concepts/cluster-administration/proxies.md
+++ b/content/id/docs/concepts/cluster-administration/proxies.md
@@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai proxy yang ada di dalam Kubernetes.
Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes:
-1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- dijalankan pada desktop pengguna atau di dalam sebuah Pod
- melakukan proxy dari alamat localhost ke apiserver Kubernetes
@@ -23,7 +23,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- mencari lokasi apiserver
- menambahkan header autentikasi
-1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- merupakan sebuah bastion yang ada di dalam apiserver
- menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau
@@ -33,7 +33,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- dapat digunakan untuk menghubungi Node, Pod, atau Service
- melakukan load balancing saat digunakan untuk menjangkau sebuah Service
-1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- dijalankan pada setiap Node
- melakukan proxy untuk UDP, TCP dan SCTP
diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md
index 8af1abba28..ee9e8bf2f4 100644
--- a/content/id/docs/concepts/configuration/assign-pod-node.md
+++ b/content/id/docs/concepts/configuration/assign-pod-node.md
@@ -7,7 +7,7 @@ weight: 30
-Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
+Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/)
@@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node:
Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
-Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
+Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
@@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
-Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
+Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
## nodeName
diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
index 3450bab459..600a4cc6cd 100644
--- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
@@ -10,7 +10,7 @@ feature:
-Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu
+Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu
dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan
oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya,
scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih
@@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_)
CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup
_sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan,
-dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/).
-Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah
+dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/).
+Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah
objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server.
## Request dan Limit Sumber daya dari Pod dan Container
@@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab
memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat
[Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
-Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk
+Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk
membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace,
kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya.
@@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node.
##### Sumber daya Device Plugin yang dikelola
Lihat [Device
-Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
+Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node.
##### Sumber daya lainnya
diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index 929c895821..caba991a8d 100644
--- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig,
bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster]
-(/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
@@ -103,7 +103,7 @@ kubeconfig:
abaikan mereka.
Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada
- [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+ [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`,
tanpa melakukan penggabungan.
@@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak.
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md
index 76d68658ec..67fb2061fe 100644
--- a/content/id/docs/concepts/configuration/overview.md
+++ b/content/id/docs/concepts/configuration/overview.md
@@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
-- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
+- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
- Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
+ Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
## Services
-- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
+- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
```shell
FOO_SERVICE_HOST=
@@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
-- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS.
+- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
- Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+ Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
- Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
+ Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
-- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless-
+- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
## Menggunakan label
-- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
+- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
-Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
+Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol.
@@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan
## Container Images
-Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
+Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
- `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal.
@@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`.
-- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md
index e59301bb96..13db4e32f8 100644
--- a/content/id/docs/concepts/configuration/pod-overhead.md
+++ b/content/id/docs/concepts/configuration/pod-overhead.md
@@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka
Pada Kubernetes, Overhead Pod ditentukan pada
[saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam
-[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod.
+[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod.
Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container
saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran
@@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u
## {{% heading "whatsnext" %}}
-* [RuntimeClass](/docs/concepts/containers/runtime-class/)
+* [RuntimeClass](/id/docs/concepts/containers/runtime-class/)
* [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md
index a0c6035482..7350470fa3 100644
--- a/content/id/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md
@@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan
1.11 | beta | ya
1.14 | stable | ya
-{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
+{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
{{< /warning >}}
@@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya
#### Penghentian secara sopan dari korban-korban pemindahan Pod
-Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
+Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
#### PodDisruptionBudget didukung, tapi tidak dijamin!
-Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
+Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
#### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah
diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md
index a6ca8dca88..40875648ff 100644
--- a/content/id/docs/concepts/configuration/secret.md
+++ b/content/id/docs/concepts/configuration/secret.md
@@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no
atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan
hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan.
-Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/)
+Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/)
untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_.
### Membuat Objek Secret Kamu Sendiri
@@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni
{{< note >}}
Sebuah container menggunakan Secret sebagai
-[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_
+[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_
yang di-_mount_ tidak akan menerima perubahan Secret.
{{< /note >}}
@@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P
**Memberikan spesifikasi manual dari sebuah imagePullSecret**
-Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan
@@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull
yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan
serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari
serviceAccount yang digunakan.
-Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
+Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
untuk informasi lebih detail soal proses yang dijalankan.
### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat
@@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_.
Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada
secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi
-akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources)
+akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources)
yang dibutuhkan aplikasi.
Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain
diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md
index 9a30b48f5b..723bbd1c9c 100644
--- a/content/id/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/id/docs/concepts/configuration/taint-and-toleration.md
@@ -6,7 +6,7 @@ weight: 40
-Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
+Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
@@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
-bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
@@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten
dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan.
{{< note >}}
-Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
+Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
pada skenario dimana master menjadi terpisah dari _node_ lainnya.
@@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi.
Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds
_admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
-_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
+_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
`NoExecute` untuk _taint_ tanpa `tolerationSeconds`:
* `node.kubernetes.io/unreachable`
diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md
index affb371001..6c0ba354e8 100644
--- a/content/id/docs/concepts/containers/container-environment.md
+++ b/content/id/docs/concepts/containers/container-environment.md
@@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada
*Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer:
-* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/).
+* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/).
* Informasi tentang Kontainer tersebut.
* Informasi tentang objek-objek lain di dalam klaster.
@@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
* Dapatkan pengalaman praktis soal
[memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
index a7b5164864..d45a5ad23e 100644
--- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
@@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono
untuk menghapus kontainer tersebut.
Tidak ada parameter yang diberikan pada *handler*.
-Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods).
### Implementasi *handler* untuk *hook*
@@ -113,7 +113,7 @@ Events:
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/).
+* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/).
* Pelajari bagaimana caranya
[melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md
index 7a5fa28154..8fa81801ff 100644
--- a/content/id/docs/concepts/containers/images.md
+++ b/content/id/docs/concepts/containers/images.md
@@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut:
- buang `imagePullPolicy` dan juga _tag_ untuk _image_.
- aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_.
-Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
+Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
## Membuat Image Multi-arsitektur dengan Manifest
@@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo
* `DOCKER_EMAIL`: `${some-email-address}`
Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat
-[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Menggunakan IBM Cloud Container Registry
IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu
@@ -291,7 +291,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER
Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas,
kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret.
-[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
+[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat,
perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan
hanya bekerja menggunakan satu registri privat.
@@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr
Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam
sumber daya [serviceAccount](/docs/user-guide/service-accounts).
-Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
+Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial
akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine.
diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md
index d31c760ee0..715230d14d 100644
--- a/content/id/docs/concepts/containers/overview.md
+++ b/content/id/docs/concepts/containers/overview.md
@@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda.
## Image-Image Kontainer
-[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak
+[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak
yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan
sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari
aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting.
diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md
index 31bd8a25ec..73252a03e4 100644
--- a/content/id/docs/concepts/containers/runtime-class.md
+++ b/content/id/docs/concepts/containers/runtime-class.md
@@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki.
Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya
konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari
yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass
-melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)).
+melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)).
{{< /note >}}
Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass.
@@ -91,7 +91,7 @@ spec:
Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut
untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat
-menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
+menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait.
Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan.
diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index d8be642856..3a3ece65b0 100644
--- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k
## _Custom Resource_
-Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
+Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular.
@@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men
Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya.
-Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
+Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini.
Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API.
@@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API
| Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan |
| Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. |
| Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. |
-| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
+| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
| Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. |
| Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. |
@@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku:
* Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui.
{{< note >}}
-Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
+Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
{{< /note >}}
Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku:
@@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar
Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu:
- CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun.
-- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
+- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan.
-_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
+_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD.
@@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll
Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition).
-[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
+[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
## Memilih sebuah metode untuk menambahkan _Custom Resource_
@@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan
## {{% heading "whatsnext" %}}
-* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 3bde2909ca..62f7c8d41d 100644
--- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim:
* Nama Unix socket-nya.
* Versi API Plugin Perangkat yang dipakai.
* `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti
- [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+ [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
sebagai `vendor-domain/tipe-sumber-daya`.
(Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.)
diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
index b7b07b46ff..9d80881724 100644
--- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
-*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
+*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
## Perluasan
@@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber
### Menggabungkan API Baru dengan Otomasi
-Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
+Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
### Mengubah Sumber Daya Bawaan
@@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo
* [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/)
* [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/)
* Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/)
-* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/)
+* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/)
diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md
index 269f7312a1..315ae35e3d 100644
--- a/content/id/docs/concepts/extend-kubernetes/operator.md
+++ b/content/id/docs/concepts/extend-kubernetes/operator.md
@@ -7,7 +7,7 @@ weight: 30
Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan
-[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip
Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane).
@@ -126,7 +126,7 @@ menggunakan bahasa / _runtime_ yang dapat bertindak sebagai
## {{% heading "whatsnext" %}}
-* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/)
untuk memenuhi use case kamu
* Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya:
diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
index efea4eda97..cd63a89355 100644
--- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
@@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API
merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut.
Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan.
-Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md
index 63e7b4b3af..aa2ee52152 100644
--- a/content/id/docs/concepts/overview/components.md
+++ b/content/id/docs/concepts/overview/components.md
@@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny
memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen
lainnya.
-[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
+[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services
Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini
@@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya.
### Web UI (Dasbor)
-[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
+[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun
aplikasi yang ada pada klaster itu sendiri.
@@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan.
### Cluster-level Logging
-[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
+[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan
pencarian.
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
index 9599feaf24..46066769d4 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
@@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k
Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
dalam dokumen ini:
@@ -862,8 +862,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
index e77cc9ca63..23489efb59 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
@@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
index 7df68f579d..94f1082e35 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
@@ -108,8 +108,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md
index 8a822f255d..aaa238add5 100644
--- a/content/id/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md
@@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku
## {{% heading "whatsnext" %}}
-Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/).
+Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
index 7cd81495cd..e46916ee3d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -3,14 +3,14 @@ title: Selektor Field
weight: 60
---
-Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
+Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*:
* `metadata.name=my-service`
* `metadata.namespace!=default`
* `status.phase=Pending`
-Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
+Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
`Running`:
```shell
@@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default
## Selektor berantai
-Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
+Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
(*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan
`Running` dan *field* `spec.restartPolicy` sama dengan `Always`:
diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 57eef5e9c6..aa702827b9 100644
--- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i
dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan.
Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu
-harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/).
+harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/).
Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah
yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki
menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan.
@@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md
index 5527c15b72..0d6528c41d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/names.md
+++ b/content/id/docs/concepts/overview/working-with-objects/names.md
@@ -8,7 +8,7 @@ weight: 20
Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID.
-Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/).
+Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/).
Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID.
diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
index 5eb358a17a..89ffb8ea14 100644
--- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
@@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster
*Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*.
-*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)).
+*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)).
Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*.
@@ -74,7 +74,7 @@ kubectl config view | grep namespace:
## Namespace dan DNS
-Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
+Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
## Tidak semua objek di dalam Namespace
diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md
index 2dbbd53144..991ebb44aa 100644
--- a/content/id/docs/concepts/policy/pod-security-policy.md
+++ b/content/id/docs/concepts/policy/pod-security-policy.md
@@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk
## Mengizinkan Kebijakan
-Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
+Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
-Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
+Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
### Melalui RBAC
-[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
+[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut:
@@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya
name: system:authenticated
```
-Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples).
Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh).
### Mengatasi Masalah
-- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
+- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles).
## Urutan Kebijakan
@@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode.
### Volume dan _file system_
-**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
+**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
**Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut:
diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md
index 47bfa996bb..c001ef4a40 100644
--- a/content/id/docs/concepts/policy/resource-quotas.md
+++ b/content/id/docs/concepts/policy/resource-quotas.md
@@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung:
### Resource Quota untuk sumber daya yang diperluas
Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk
-[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
+[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan
keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk
@@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi
## Resource Quota untuk penyimpanan
-Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat
+Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat
diminta pada sebuah Namespace.
Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_
@@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut.
| Nama Sumber Daya | Deskripsi |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. |
-| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
| `.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. |
-| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut:
@@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung:
| Nama Sumber Daya | Deskripsi |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. |
-| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
+| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
| `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. |
| `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. |
| `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. |
@@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k
{{< feature-state for_k8s_version="1.12" state="beta" >}}
-Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
+Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan
kolom `scopeSelector` pada spesifikasi kuota tersebut.
diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md
index f4cd477608..6f7efab3d9 100644
--- a/content/id/docs/concepts/scheduling/kube-scheduler.md
+++ b/content/id/docs/concepts/scheduling/kube-scheduler.md
@@ -94,10 +94,10 @@ penilaian oleh penjadwal:
## {{% heading "whatsnext" %}}
-* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/)
-* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_
* Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/)
-* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/)
+* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/)
diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
index 0a20d9050a..3689ecf7cb 100644
--- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
+++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -8,7 +8,7 @@ weight: 70
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
-[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
+[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
@@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim
persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
-akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md
index caff040bc5..bc271e0645 100644
--- a/content/id/docs/concepts/security/overview.md
+++ b/content/id/docs/concepts/security/overview.md
@@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi
## {{% heading "whatsnext" %}}
-* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/)
+* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/)
* Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/)
* Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/)
-* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/)
-* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/)
+* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/)
diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md
index 4bbd0bbf56..806fff3a46 100644
--- a/content/id/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/id/docs/concepts/services-networking/connect-applications-service.md
@@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
-Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
+Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
## Membuat Service
@@ -107,7 +107,7 @@ NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
```
-Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
+Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
## Mengakses Service
@@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum
* *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*)
* Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut
-* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
+* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya:
@@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
## {{% heading "whatsnext" %}}
-Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
+Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md
index 52ec19a420..efdba8d7a1 100644
--- a/content/id/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/id/docs/concepts/services-networking/dns-pod-service.md
@@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada.
### SRV _record_
SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless
-Services](/docs/concepts/services-networking/service/#headless-services).
+Services](/id/docs/concepts/services-networking/service/#headless-services).
Untuk setiap port bernama, SRV _record_ akan memiliki format
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan
diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md
index 224e7b4bbd..1782f4273e 100644
--- a/content/id/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/id/docs/concepts/services-networking/endpoint-slices.md
@@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki
referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan
_endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik.
Nama dari sebuah objek EndpointSlice haruslah berupa
-[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
+[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes
yang bernama `example`.
@@ -180,6 +180,6 @@ bersangkutan.
* [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md
index 9491f5dc1c..645f2dbf8d 100644
--- a/content/id/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/id/docs/concepts/services-networking/ingress-controllers.md
@@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang
## {{% heading "whatsnext" %}}
-* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut.
+* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut.
* [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube)
diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md
index 617581b421..1cc56c5960 100644
--- a/content/id/docs/concepts/services-networking/ingress.md
+++ b/content/id/docs/concepts/services-networking/ingress.md
@@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak
* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes.
* Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
-* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
-* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
+* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/).
+* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
## Apakah *Ingress* itu?
@@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa
```
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
-Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
+Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan
-*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau
-[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
+*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau
+[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer).
## Prasyarat
@@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se
Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta.
{{< note >}}
-Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
+Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
{{< /note >}}
GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut
@@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE.
Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus
[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis
-[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
+[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
### Sebelum kamu memulai
@@ -89,10 +89,10 @@ spec:
```
Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`.
- Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/).
+ Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/).
Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
+ [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan.
[Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress
@@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum
*loadbalancer* akan mengarahkan trafik pada *service* yang sesuai.
* Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di
- [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
+ [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
*host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait.
*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah
@@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
### *Backend Default*
Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang
-biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
+biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut
akan diarahkan pada *backend default*.
@@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga
pada kolom `address`.
{{< note >}}
-Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/)
-bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
+Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/)
+bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
{{< /note >}}
### Virtual Host berbasis Nama
@@ -291,7 +291,7 @@ spec:
### TLS
-Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret)
+Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret)
yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya
memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS.
Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda,
@@ -448,8 +448,8 @@ Ingress yang ingin diubah.
## Mekanisme *failing* pada beberapa zona *availability*
Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*.
-Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers)
-untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/)
+Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers)
+untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/)
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster.
## Pengembangan selanjutnya
@@ -463,8 +463,8 @@ soal perubahan berbagai kontroler.
Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan:
-* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
-* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer)
+* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport)
* [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md
index 25f42ddb98..fe510b846d 100644
--- a/content/id/docs/concepts/services-networking/network-policies.md
+++ b/content/id/docs/concepts/services-networking/network-policies.md
@@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy.
**_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy`
membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai
bagaimana bekerja dengan _file_ `config`, dapat dilihat di
-[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/),
serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/).
**spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu.
diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md
index ef15d1ab3d..05abffa323 100644
--- a/content/id/docs/concepts/services-networking/service-topology.md
+++ b/content/id/docs/concepts/services-networking/service-topology.md
@@ -186,5 +186,5 @@ spec:
* Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology)
-* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md
index 97626bf9ce..00bf4e6241 100644
--- a/content/id/docs/concepts/services-networking/service.md
+++ b/content/id/docs/concepts/services-networking/service.md
@@ -12,9 +12,9 @@ weight: 10
-[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
+[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut
-tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara
+tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara
khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*).
Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP
yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
@@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada.
Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi
set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_.
-Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors)
(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa
sebuah _selector_).
@@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja:
* Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_,
kamu ingin menggunakan basis datamu sendiri.
* Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada
- [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
+ [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
* Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih
berada di luar klaster Kubernetes.
@@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini.
### DNS
-Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional
+Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional
(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah
terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis
@@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_.
Server DNS Kubernetes adalah satu-satunya cara untuk mengakses
_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di
-[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/).
+[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/).
## `Service` _headless_
@@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun.
Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan
_DaemonSet_ atau melakukan spesifikasi
-[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
+[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
agar `Pod` tidak di-_assign_ ke _node_ yang sama.
-NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer).
+NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer).
Agar trafik klien berhasil mencapai _instances_ dibelakang ELB,
_security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut:
@@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS.
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)),
_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_
di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks
[protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md
index ac206dfacd..4b9fa6f35c 100644
--- a/content/id/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/id/docs/concepts/storage/dynamic-provisioning.md
@@ -8,7 +8,7 @@ weight: 40
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus
-memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
+memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/)
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
ketika diminta oleh pengguna.
@@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
memilih berbagai macam pilihan penyimpanan.
-Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/).
+Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/).
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
@@ -123,6 +123,6 @@ tidak bisa terbuat.
Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
-[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
+[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md
index f75941b86a..51163d36a9 100644
--- a/content/id/docs/concepts/storage/persistent-volumes.md
+++ b/content/id/docs/concepts/storage/persistent-volumes.md
@@ -11,7 +11,7 @@ weight: 20
-Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/).
+Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/).
@@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl
kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya
`StorageClass`.
-Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
## Siklus hidup dari sebuah volume dan klaim
@@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi:
Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut
`storageClassName` menjadi nama
-[StorageClass](/docs/concepts/storage/storage-classes/).
+[StorageClass](/id/docs/concepts/storage/storage-classes/).
Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta
kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat
dengan PVC yang tidak meminta kelas tertentu.
@@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.
### Afinitas Node
{{< note >}}
-Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local).
+Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local).
{{< /note >}}
Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_.
@@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas
### _Selector_
-Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
+Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
* `matchLabels` - volume harus memiliki label dengan nilai ini
* `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist.
@@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak
### Kelas
Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari
-[StorageClass](/docs/concepts/storage/storage-classes/)
+[StorageClass](/id/docs/concepts/storage/storage-classes/)
menggunakan atribut `storageClassName`.
Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat
terikat dengan PVC.
@@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/).
+Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/).
Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan
gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_.
diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md
index 9e0a5b1664..2897399e80 100644
--- a/content/id/docs/concepts/storage/storage-classes.md
+++ b/content/id/docs/concepts/storage/storage-classes.md
@@ -8,8 +8,8 @@ weight: 30
Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes.
Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap
-[volumes](/docs/concepts/storage/volumes/) dan
-[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu.
+[volumes](/id/docs/concepts/storage/volumes/) dan
+[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu.
@@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.
Administrator dapat memberikan spesifikasi StorageClass _default_ bagi
PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_:
-kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
untuk penjelasan lebih lanjut.
```yaml
@@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid.
### Mode Volume _Binding_
_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan
-_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning)
+_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning)
harus dilakukan.
Secara _default_, ketika mode `Immediate` yang mengindikasikan
@@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan
PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_
sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan
oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada,
-[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container),
-[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector),
+[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container),
+[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector),
[afinitas dan
-anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
-serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration).
+anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration).
Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_
dinamis:
@@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat:
* [Lokal](#lokal)
{{< feature-state state="beta" for_k8s_version="1.14" >}}
-[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung
+[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung
dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat,
meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi
untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung
@@ -634,8 +634,8 @@ parameters:
di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan.
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster
-menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan
-[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles),
+menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan
+[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles),
menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole
`system:controller:persistent-volume-binder`.
diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md
index 4a5f5d8c8c..481e74c976 100644
--- a/content/id/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md
@@ -7,7 +7,7 @@ weight: 30
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan.
+Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan.
diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md
index 0414a9d7de..fff7de9baa 100644
--- a/content/id/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,8 +7,8 @@ weight: 30
Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan,
-sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/)
-dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu.
+sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/)
+dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu.
diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md
index 39ab3d31aa..5ddfc2aaa6 100644
--- a/content/id/docs/concepts/storage/volume-snapshots.md
+++ b/content/id/docs/concepts/storage/volume-snapshots.md
@@ -7,7 +7,7 @@ weight: 20
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
+Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
@@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing
#### Dinamis
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot.
-Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi.
### Ikatan (_Binding_)
@@ -93,7 +93,7 @@ spec:
### _Class_
Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut
-`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
+`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/).
VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang
"meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat
terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_.
@@ -117,7 +117,7 @@ spec:
### _Class_
Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
menggunakan atribut `snapshotClassName`.
Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama
dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
@@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan
menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim.
-Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
+Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md
index 679de8c865..8d593f1eba 100644
--- a/content/id/docs/concepts/storage/volumes.md
+++ b/content/id/docs/concepts/storage/volumes.md
@@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk
### configMap {#configmap}
-Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
+Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod.
Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini:
@@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang
Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`.
{{< caution >}}
-Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
+Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
{{< /caution >}}
{{< note >}}
@@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r
#### Menyediakan sebuah Regional PD PersistentVolume Secara Manual
-Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce).
+Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce).
Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya:
```shell
@@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc
Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`.
-Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
+Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner).
@@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github
### persistentVolumeClaim {#persistentvolumeclaim}
-Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
+Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
-Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
+Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
### projected {#projected}
@@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github
### scaleIO {#scaleio}
-ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
+ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)).
{{< caution >}}
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
@@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya
Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`.
-Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
+Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
#### Volume CSI Sementara
diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
index 29fde331ea..ca5df2d86d 100644
--- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
@@ -6,7 +6,7 @@ weight: 80
-Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
+Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala
pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron).
@@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik
Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi.
{{< /note >}}
-Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs).
+Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs).
diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md
index baa79aa3f2..0b1c0e71e9 100644
--- a/content/id/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/id/docs/concepts/workloads/controllers/daemonset.md
@@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_
`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/),
-[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/).
+[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/).
DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib
Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus
menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)).
-Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`.
DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer
keluar/berhenti atau terjadi _crash_.
@@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m
Objek `.spec.selector` memiliki dua _field_:
-* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/).
* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih
dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan
hubungan antara _key_ dan _value_.
@@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_.
Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan
membuat Pod pada Node yang cocok dengan [selektor
-Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
-maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/).
+Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
+maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/).
Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan
membuat Pod pada semua Node.
@@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut:
* Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat
dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini
membingungkan untuk pengguna.
- * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
+ * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/)
ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan,
_controller_ DaemonSet akan membuat keputusan penjadwalan tanpa
memperhitungkan prioritas Pod dan _preemption_.
@@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet.
### _Taint_ dan _Toleration_
Meskipun Pod Daemon menghormati
-[taint dan toleration](/docs/concepts/configuration/taint-and-toleration),
+[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration),
_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai
dengan fitur yang bersangkutan.
@@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon
- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain,
contohnya _stats database_. Pod ini tidak memiliki klien.
- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi.
-- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
+- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS.
- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada
Node random. (Tidak ada cara mengakses spesifik Node)
@@ -223,7 +223,7 @@ _bootstrapping_ klaster.
### Deployment
-DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka
+DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka
sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web,
peladen penyimpanan)
diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
index 4aca03535f..5f4720646b 100644
--- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community
_Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`.
-_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
+_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`.
Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job
haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor))
dan sebuah mekanisme _restart_ yang sesuai.
-Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
+Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
### Selektor Pod
@@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak
akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian,
program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika
tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan
-[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
+[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja,
ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau
@@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan.
Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan
objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job
yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti
-[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
+[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan.
### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan
@@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif
Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan
(baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan
menerapkan mekanisme TTL yang disediakan oleh
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan
_field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut.
@@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di
Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`.
Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai dijalankan.
## Pola Job
@@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati
Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job
mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_).
-Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
+Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`.
(Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.)
@@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y
## CronJob {#cron-jobs}
-Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
+Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix.
diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md
index c0c3a83d51..57b1124208 100644
--- a/content/id/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/id/docs/concepts/workloads/controllers/replicaset.md
@@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
+_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
```shell
matchLabels:
tier: frontend
@@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_
### Menghapus ReplicaSet dan Pod-nya
-Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
+Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d.
Sebagai contoh:
@@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
```
Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru.
-Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
+Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
### Mengisolasi Pod dari ReplicaSet
@@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10
### Deployment (direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri.
Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.
@@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
### ReplicationController
-ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
+ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
index f828ff9c64..48ec718a6d 100644
--- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -13,7 +13,7 @@ weight: 20
{{< note >}}
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
{{< /note >}}
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
@@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
-Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
+Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/).
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
-`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
+`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
-Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
+Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
@@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
+_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
@@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern
### ReplicaSet
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
+[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
### Deployment (Direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
### Pod sederhana
@@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
## Informasi lanjutan
diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md
index 9d12de91dd..aa99acd6e6 100644
--- a/content/id/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/id/docs/concepts/workloads/controllers/statefulset.md
@@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada
Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau
mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan
-replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
-[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
+replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau
+[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
## Keterbatasan
@@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads
pada Kubernetes rilis sebelum versi 1.5.
* Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator.
* Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait.
-* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
+* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan
[Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default,
@@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet.
* Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan.
* StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik.
-* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
+* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
```yaml
apiVersion: v1
@@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul
serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah
`$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod
dengan nama `web-0,web-1,web-2`.
-Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain klaster.
@@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi
_field_ `serviceName` pada StatefulSet.
Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab
-untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.
Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service,
@@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
{{< note >}}
Domain klaster akan diatur menjadi `cluster.local` kecuali
-[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/).
+[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Penyimpanan Stabil
-Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
+Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap
VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume
dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_
diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
index f2c232faf2..0e1b36ccc5 100644
--- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -10,7 +10,7 @@ weight: 65
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
+[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/),
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
@@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
-[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
dilakukan secara berantai, dimana sumber daya lain yang
@@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai
## {{% heading "whatsnext" %}}
-[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md
index 1adde6c949..7a09eed3a5 100644
--- a/content/id/docs/concepts/workloads/pods/disruptions.md
+++ b/content/id/docs/concepts/workloads/pods/disruptions.md
@@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod
PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB.
-Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).))
diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
index 45154caf25..e952bdd19b 100644
--- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan
menggunakan `kubectl exec` saja.
Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan
-[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/)
+[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/)
sehingga kamu dapat melihat proses pada kontainer lain.
### Contoh
diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md
index 91807fdaf6..9cd208fbc8 100644
--- a/content/id/docs/concepts/workloads/pods/init-containers.md
+++ b/content/id/docs/concepts/workloads/pods/init-containers.md
@@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp
## Memahami Init Container
-Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
+Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
Init Container sama saja seperti Container biasa, kecuali:
@@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container:
* Mengklon sebuah _git repository_ ke dalam sebuah _volume_.
* Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.
-Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
+Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
### Menggunakan Init Container
diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
index 8dac6706a7..fdb3e7b71c 100644
--- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions]
* `PodScheduled`: Pod telah dijadwalkan masuk ke node;
* `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;
- * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
+ * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
* `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain.
* `ContainersReady`: Semua kontainer di dalam Pod telah siap.
@@ -191,7 +191,7 @@ status:
...
```
-Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
+Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan
salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/).
@@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu:
sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang
bernilai OnFailure atau Never.
-- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau
- [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
+- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/),
+ [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau
+ [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy`
yang bernilai Always.
-- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
+- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
@@ -346,7 +346,7 @@ spec:
* Dapatkan pengalaman langsung mengenai
[pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
-* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md
index 0e9593e0d1..f427358999 100644
--- a/content/id/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/id/docs/concepts/workloads/pods/pod-overview.md
@@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod*
#### Penyimpanan
-*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
+*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
## Bekerja dengan Pod
@@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika
Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi:
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*.
## Templat Pod
Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
+[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan.
@@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem
## {{% heading "whatsnext" %}}
* Pelajari lebih lanjut tentang perilaku *Pod*:
- * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
+ * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods)
+ * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md
index 3838ec56b5..e25a3a9104 100644
--- a/content/id/docs/concepts/workloads/pods/pod.md
+++ b/content/id/docs/concepts/workloads/pods/pod.md
@@ -39,7 +39,7 @@ dan bisa saling berkomunikasi melalui `localhost`. Komunikasi tersebut mengunaka
standar _inter-process communications_ (IPC) seperti SystemV semaphores
atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP
yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa
-[pengaturan khusus](/docs/concepts/policy/pod-security-policy/). Kontainer ini
+[pengaturan khusus](/id/docs/concepts/policy/pod-security-policy/). Kontainer ini
biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod.
Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama,
@@ -51,14 +51,14 @@ gabungan dari kontainer Docker yang berbagi _namespace_ dan ruang penyimpanan _f
Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal
(tidak bertahan lama). Seperti yang didiskusikan dalam
-[siklus hidup Pod](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
+[siklus hidup Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan
(bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}}
mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah
suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang
ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa
dengan nama yang sama, tapi dengan ID unik yang baru
-(baca [_replication controller_](/docs/concepts/workloads/controllers/replicationcontroller/)
+(baca [_replication controller_](/id/docs/concepts/workloads/controllers/replicationcontroller/)
untuk info lebih lanjut)
Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan,
@@ -96,7 +96,7 @@ dan Pod lain dalam jaringan yang sama.
Kontainer dalam suatu Pod melihat _hostname_ sistem sebagai sesuatu yang sama
dengan konfigurasi `name` pada Pod. Informasi lebih lanjut terdapat dibagian
-[jaringan](/docs/concepts/cluster-administration/networking/).
+[jaringan](/id/docs/concepts/cluster-administration/networking/).
Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod,
Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan
@@ -153,10 +153,10 @@ kasus mesin sedang dalam pemeliharaan.
Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka
seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya,
-[_Deployment_](/docs/concepts/workloads/controllers/deployment/). Pengontrol
+[_Deployment_](/id/docs/concepts/workloads/controllers/deployment/). Pengontrol
menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan
pengelolaan replikasi dan penluncuran.
-Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md)
+Pengontrol seperti [_StatefulSet_](/id/docs/concepts/workloads/controllers/statefulset.md)
bisa memberikan dukungan terhadap Pod yang _stateful_.
Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang
@@ -202,7 +202,7 @@ bersama dengan masa tenggang.
1. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai
"Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod
1. Jika salah satu kontainer pada Pod memiliki
- [preStop _hook_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
+ [preStop _hook_](/id/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
maka akan dipanggil di dalam kontainer. Jika `preStop` _hook_ masih berjalan
setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang
yang sedikit, 2 detik.
@@ -223,7 +223,7 @@ Secara _default_, semua penghapusan akan berjalan normal selama 30 detik. Perint
`kubectl delete` mendukung opsi `--grace-period=` yang akan
memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan
pengguna. Nilai `0` akan membuat Pod
-[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
+[dihapus paksa](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
Kamu harus memberikan opsi tambahan `--force` bersamaan dengan `--grace-period=0`
untuk melakukan penghapusan paksa.
@@ -243,7 +243,7 @@ dokumentasi untuk [penghentian Pod dari StatefulSet](/docs/tasks/run-application
## Hak istimewa untuk kontainer pada Pod
Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _privileged_), dengan menggunakan tanda
-`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/)
+`privileged` pada [konteks keamanan](/id/docs/tasks/configure-pod-container/security-context/)
pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan
kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam
kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer.
diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md
index 2fc1b8598b..9b899c4687 100644
--- a/content/id/docs/concepts/workloads/pods/podpreset.md
+++ b/content/id/docs/concepts/workloads/pods/podpreset.md
@@ -57,6 +57,6 @@ Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus mema
## {{% heading "whatsnext" %}}
- * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
+ * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/id/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md
index 8dd4c02c3a..49aa20ed6e 100644
--- a/content/id/docs/reference/access-authn-authz/rbac.md
+++ b/content/id/docs/reference/access-authn-authz/rbac.md
@@ -24,7 +24,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
## Objek API {#api-overview}
API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole,
-RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
+RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
{{< caution >}}
Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan
@@ -100,7 +100,7 @@ rules:
verbs: ["get", "watch", "list"]
```
-Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
### RoleBinding dan ClusterRoleBinding
@@ -116,7 +116,7 @@ Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu
ClusterRoleBinding.
Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan
-[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+[nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
#### Contoh RoleBinding
@@ -456,7 +456,7 @@ Di Kubernetes, modul otentikasi menyediakan informasi grup.
Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu,
selain awalan `system:` yang sudah direservasi.
-[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
+[ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
{{< note >}}
- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_.
@@ -1077,7 +1077,7 @@ In order from most secure to least secure, the approaches are:
--namespace=my-namespace
```
- Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+ Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the
"default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin
permissions to the "default" service account in the `kube-system` namespace.
diff --git a/content/id/docs/reference/kubectl/cheatsheet.md b/content/id/docs/reference/kubectl/cheatsheet.md
index 9afe999064..671ac6b77a 100644
--- a/content/id/docs/reference/kubectl/cheatsheet.md
+++ b/content/id/docs/reference/kubectl/cheatsheet.md
@@ -319,8 +319,8 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### Berbagai Tipe Sumber Daya
-Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/docs/concepts/overview/kubernetes-api/#api-groups),
-apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups),
+apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/id/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
diff --git a/content/id/docs/setup/production-environment/tools/_index.md b/content/id/docs/setup/production-environment/tools/_index.md
new file mode 100644
index 0000000000..fc98544230
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/_index.md
@@ -0,0 +1,4 @@
+---
+title: Menginstal Kubernetes dengan perkakas penyebaran
+weight: 30
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/_index.md b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
new file mode 100644
index 0000000000..f88a749c9b
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Menyiapkan klaster dengan kubeadm"
+weight: 10
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index e0db168ccd..8a345296a3 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -66,7 +66,7 @@ Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _a
### Menginstal kubeadm pada hos
-Lihat ["Menginstal kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+Lihat ["Menginstal kubeadm"](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
{{< note >}}
Jika kamu sudah menginstal kubeadm sebelumnya, jalankan `apt-get update &&
@@ -94,7 +94,7 @@ yang spesifik pada penyedia tertentu. Lihat [Menginstal _add-on_ jaringan Pod](#
3. (Opsional) Sejak versi 1.14, `kubeadm` mencoba untuk mendeteksi _runtime_ kontainer pada Linux
dengan menggunakan daftar _domain socket path_ yang umum diketahui. Untuk menggunakan _runtime_ kontainer yang berbeda atau
jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen `--cri-socket`
-pada `kubeadm init`. Lihat [Menginstal _runtime_](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+pada `kubeadm init`. Lihat [Menginstal _runtime_](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
4. (Opsional) Kecuali ditentukan sebelumnya, `kubeadm` akan menggunakan antarmuka jaringan yang diasosiasikan
dengan _default gateway_ untuk mengatur alamat _advertise_ untuk API Server pada Node _control-plane_ ini.
Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen `--apiserver-advertise-address=`
@@ -262,7 +262,7 @@ DNS klaster (CoreDNS) tidak akan menyala sebelum jaringan dipasangkan.**
`--pod-network-cidr`, atau sebagai penggantinya pada YAML _plugin_ jaringan kamu).
- Secara bawaan, `kubeadm` mengatur klastermu untuk menggunakan dan melaksanakan penggunaan
- [RBAC](/docs/reference/access-authn-authz/rbac/) (_role based access control_).
+ [RBAC](/id/docs/reference/access-authn-authz/rbac/) (_role based access control_).
Pastikan _plugin_ jaringan Pod mendukung RBAC, dan begitu juga seluruh manifes
yang kamu gunakan untuk men-_deploy_-nya.
@@ -571,14 +571,14 @@ opsinya.
untuk detail mengenai pembaruan klaster menggunakan `kubeadm`.
* Pelajari penggunaan `kubeadm` lebih lanjut pada [dokumentasi referensi kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm)
* Pelajari lebih lanjut mengenai [konsep-konsep](/docs/concepts/) Kubernetes dan [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Lihat halaman [Cluster Networking](/docs/concepts/cluster-administration/networking/) untuk daftar
+* Lihat halaman [Cluster Networking](/id/docs/concepts/cluster-administration/networking/) untuk daftar
_add-on_ jaringan Pod yang lebih banyak.
-* Lihat [daftar _add-on_](/docs/concepts/cluster-administration/addons/) untuk
+* Lihat [daftar _add-on_](/id/docs/concepts/cluster-administration/addons/) untuk
mengeksplor _add-on_ lainnya, termasuk perkakas untuk _logging_, _monitoring_, _network policy_, visualisasi &
pengendalian klaster Kubernetes.
* Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari
aplikasi-aplikasi yang berjalan pada Pod.
- Lihat [Arsitektur Logging](/docs/concepts/cluster-administration/logging/) untuk
+ Lihat [Arsitektur Logging](/id/docs/concepts/cluster-administration/logging/) untuk
gambaran umum tentang hal-hal yang terlibat.
### Umpan balik
@@ -602,7 +602,7 @@ Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v{{< skew latestVers
Sumber daya ini menyediakan informasi lebih lanjut mengenai _version skew_ yang didukung antara kubelet dan _control plane_, serta komponen Kubernetes lainnya:
* [Kebijakan versi and version-skew Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Panduan instalasi](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
+* [Panduan instalasi](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
## Keterbatasan
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
new file mode 100644
index 0000000000..afe6d1e6b8
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -0,0 +1,364 @@
+---
+title: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm
+content_type: task
+weight: 60
+---
+
+
+
+Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm:
+
+- Dengan Node _control plane_ yang bertumpuk (_stacked_). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node _control plane_ diletakkan pada tempat yang sama (_co-located_).
+- Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node _control plane_ dan anggota etcd berada pada tempat yang berbeda.
+
+Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan _environment_-mu. [Topik perbandingan berikut](/id/docs/setup/production-environment/tools/kubeadm/ha-topology/) menguraikan kelebihan dan kekurangan dari masing-masing pendekatan.
+
+Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik
+pada [pelacak isu](https://github.com/kubernetes/kubeadm/issues/new) kubeadm.
+
+Lihat juga [dokumentasi pembaruan](/id/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+
+{{< caution >}}
+Laman ini tidak menunjukkan cara untuk menjalankan klastermu pada penyedia layanan cloud. Pada _environment_ cloud, kedua pendekatan yang didokumentasikan di sini tidak akan bekerja untuk objek Service dengan tipe LoadBalancer maupun PersistentVolume dinamis.
+{{< /caution >}}
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut:
+
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk
+ Node _control plane_
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk Node _worker_
+- Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi)
+- Hak akses sudo pada seluruh mesin
+- Akses SSH dari satu perangkat ke seluruh Node pada sistem
+- Perkakas `kubeadm` dan `kubelet` diinstal pada seluruh mesin. Perkakas `kubectl` bersifat opsional.
+
+Untuk klaster etcd eksternal saja, kamu juga membutuhkan:
+
+- Tiga mesin tambahan untuk anggota-anggota etcd
+
+
+
+
+
+## Langkah pertama untuk kedua metode
+
+### Membuat _load balancer_ untuk kube-apiserver
+
+{{< note >}}
+Akan ada banyak konfigurasi untuk _load balancer_. Contoh berikut ini hanyalah salah satu
+opsi. Kebutuhan klastermu mungkin membutuhkan konfigurasi berbeda.
+{{< /note >}}
+
+1. Buat sebuah _load balancer_ kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS.
+
+ - Pada _environment_ cloud kamu harus meletakkan Node _control plane_ di belakang _load balancer_ yang meneruskan TCP. _Load balancer_ ini mendistribusikan trafik ke seluruh Node _control plane_ pada daftar tujuan. _Health check_ untuk
+ apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver
+ (nilai semula `:6443`).
+
+ - Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada _environment_ cloud.
+
+ - _Load balancer_ harus dapat berkomunikasi dengan seluruh Node _control plane_
+ pada porta yang digunakan apiserver. _Load balancer_ tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya.
+
+ - Pastikan alamat _load balancer_ sesuai
+ dengan alamat `ControlPlaneEndpoint` pada kubeadm.
+
+ - Baca panduan [Opsi untuk _Software Load Balancing_](https://github.com/kubernetes/kubeadm/blob/master/id/docs/ha-considerations.md#options-for-software-load-balancing)
+ untuk detail lebih lanjut.
+
+2. Tambahkan Node _control plane_ pertama pada _load balancer_ dan lakukan pengujian koneksi:
+
+ ```sh
+ nc -v LOAD_BALANCER_IP PORT
+ ```
+
+ - Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum
+ berjalan. Namun jika mendapat _timeout_, berarti _load balancer_ tidak dapat berkomunikasi
+ dengan Node _control plane_. Jika terjadi _timeout_, lakukan pengaturan ulang pada _load balancer_ agar dapat berkomunikasi dengan Node _control plane_.
+
+3. Tambahkan Node _control plane_ lainnya pada grup tujuan _load balancer_.
+
+## Node _control plane_ dan etcd bertumpuk (_stacked_)
+
+### Langkah-langkah untuk Node _control plane_ pertama
+
+1. Inisialisasi _control plane_:
+
+ ```sh
+ sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
+ ```
+
+ - Kamu bisa menggunakan opsi `--kubernetes-version` untuk mengatur versi Kubernetes yang akan digunakan.
+ Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama.
+
+ - Opsi `--control-plane-endpoint` harus diatur menuju alamat atau DNS dan porta dari _load balancer_.
+
+ - Opsi `--upload-certs` digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh
+ Node _control plane_ pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke
+ seluruh Node _control plane_ sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian [Distribusi sertifikat manual](#distribusi-sertifikat-manual) di bawah.
+
+ {{< note >}}
+ Opsi `--config` dan `--certificate-key` pada `kubeadm init` tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan
+ [konfigurasi kubeadm](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
+ kamu harus menambahkan _field_ `certificateKey` pada lokasi pengaturan yang sesuai
+ (berada di bawah `InitConfiguration` dan `JoinConfiguration: controlPlane`).
+ {{< /note >}}
+
+ {{< note >}}
+ Beberapa _plugin_ jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak.
+ Lihat [dokumentasi jaringan CNI](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod).
+ Untuk menambahkan CIDR Pod, tambahkan opsi `--pod-network-cidr`, atau jika kamu menggunakan berkas konfigurasi kubeadm
+ pasang _field_ `podSubnet` di bawah objek `networking` dari `ClusterConfiguration`.
+ {{< /note >}}
+
+ - Keluaran yang dihasilkan terlihat seperti berikut ini:
+
+ ```sh
+ ...
+ You can now join any number of control-plane node by running the following command on each as a root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+
+ Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+ As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+
+ Then you can join any number of worker nodes by running the following on each as root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+ ```
+
+ - Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node _control plane_ dan _worker_ ke klaster.
+ - Ketika opsi `--upload-certs` digunakan dengan `kubeadm init`, sertifikat dari _control plane_ utama
+ akan dienkripsi dan diunggah ke Secret `kubeadm-certs`.
+ - Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node _control plane_
+ yang sudah tergabung pada klaster:
+
+ ```sh
+ sudo kubeadm init phase upload-certs --upload-certs
+ ```
+
+ - Kamu juga dapat menentukan `--certificate-key` _custom_ pada saat `init` yang nanti dapat digunakan pada saat `join`.
+ Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut:
+
+ ```sh
+ kubeadm alpha certs certificate-key
+ ```
+
+ {{< note >}}
+ Secret `kubeadm-certs` dan kunci dekripsi akan kadaluarsa setelah dua jam.
+ {{< /note >}}
+
+ {{< caution >}}
+ Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya!
+ {{< /caution >}}
+
+2. Pasang _plugin_ CNI pilihanmu:
+ [Ikuti petunjuk berikut](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod)
+ untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan.
+
+ Pada contoh berikut kami menggunakan Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+3. Tulis perintah berikut dan saksikan Pod komponen-komponen _control plane_ mulai dinyalakan:
+
+ ```sh
+ kubectl get pod -n kube-system -w
+ ```
+
+### Langkah-langkah selanjutnya untuk Node _control plane_
+
+{{< note >}}
+Sejak kubeadm versi 1.15 kamu dapat menggabungkan beberapa Node _control plane_ secara bersamaan.
+Pada versi sebelumnya, kamu harus menggabungkan Node _control plane_ baru secara berurutan, setelah
+Node pertama selesai diinisialisasi.
+{{< /note >}}
+
+Untuk setiap Node _control plane_ kamu harus:
+
+1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran `kubeadm init` pada Node pertama.
+ Perintah tersebut terlihat seperti ini:
+
+ ```sh
+ sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+ ```
+
+ - Opsi `--control-plane` menunjukkan `kubeadm join` untuk membuat _control plane_ baru.
+ - Opsi `--certificate-key ...` akan membuat sertifikat _control plane_ diunduh
+ dari Secret `kubeadm-certs` pada klaster dan didekripsi menggunakan kunci yang diberikan.
+
+## Node etcd eksternal
+
+Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk
+dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd
+pada berkas konfigurasi kubeadm.
+
+### Memasang klaster etcd
+
+1. Ikuti [petunjuk berikut](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk membangun klaster etcd.
+
+2. Lakukan pengaturan SSH seperti yang dijelaskan [di sini](#distribusi-sertifikat-manual).
+
+3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node _control plane_ pertama:
+
+ ```sh
+ export CONTROL_PLANE="ubuntu@10.0.0.7"
+ scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
+ ```
+
+ - Ganti nilai `CONTROL_PLANE` dengan `user@host` dari mesin _control plane_ pertama.
+
+### Mengatur Node _control plane_ pertama
+
+1. Buat sebuah berkas bernama `kubeadm-config.yaml` dengan konten sebagai berikut:
+
+ apiVersion: kubeadm.k8s.io/v1beta2
+ kind: ClusterConfiguration
+ kubernetesVersion: stable
+ controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+ etcd:
+ external:
+ endpoints:
+ - https://ETCD_0_IP:2379
+ - https://ETCD_1_IP:2379
+ - https://ETCD_2_IP:2379
+ caFile: /etc/kubernetes/pki/etcd/ca.crt
+ certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+ keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+
+ {{< note >}}
+ Perbedaan antara etcd bertumpuk dan etcd eksternal yaitu etcd eksternal membutuhkan
+ sebuah berkas konfigurasi dengan _endpoint_ etcd di bawah objek `external`untuk `etcd`.
+ Pada kasus ini topologi etcd bertumpuk dikelola secara otomatis.
+ {{< /note >}}
+
+ - Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu:
+
+ - `LOAD_BALANCER_DNS`
+ - `LOAD_BALANCER_PORT`
+ - `ETCD_0_IP`
+ - `ETCD_1_IP`
+ - `ETCD_2_IP`
+
+Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk:
+
+1. Jalankan `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` pada Node ini.
+
+2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti.
+
+3. Pasang _plugin_ CNI pilihanmu. Contoh berikut ini untuk Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+### Langkah selanjutnya untuk Node _control plane_ lainnya
+
+Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk:
+
+- Pastikan Node _control plane_ pertama sudah diinisialisasi dengan sempurna.
+- Gabungkan setiap Node _control plane_ dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk
+menggabungkan Node _control plane_ satu persatu.
+- Jangan lupakan bahwa kunci dekripsi dari `--certificate-key` akan kadaluarsa setelah dua jam, pada pengaturan semula.
+
+## Tugas-tugas umum setelah menyiapkan _control plane_
+
+### Menginstal _worker_
+
+Node _worker_ bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya
+dari keluaran perintah `kubeadm init`:
+
+```sh
+sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+```
+
+## Distribusi sertifikat manual
+
+Jika kamu memilih untuk tidak menggunakan `kubeadm init` dengan opsi `--upload-certs` berarti kamu harus
+menyalin sertifikat dari Node _control plane_ utama secara manual ke
+Node _control plane_ yang akan bergabung.
+
+Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan `ssh` dan `scp`:
+
+SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin.
+
+1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada
+ sistem:
+
+ ```
+ eval $(ssh-agent)
+ ```
+
+2. Tambahkan identitas SSH milikmu ke dalam sesi:
+
+ ```
+ ssh-add ~/.ssh/path_to_private_key
+ ```
+
+3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik.
+
+ - Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi `-A`:
+
+ ```
+ ssh -A 10.0.0.7
+ ```
+
+ - Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan _environment_ yang ada sehingga penerusan SSH
+ dapat bekerja dengan baik:
+
+ ```
+ sudo -E -s
+ ```
+
+4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node _control plane_ pertama setelah
+ menjalankan `kubeadm init`. Skrip ini akan menyalin sertifikat dari Node _control plane_ pertama ke Node
+ _control plane_ lainnya:
+
+ Pada contoh berikut, ganti `CONTROL_PLANE_IPS` dengan alamat IP dari
+ Node _control plane_ lainnya.
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
+ for host in ${CONTROL_PLANE_IPS}; do
+ scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
+ done
+ ```
+
+ {{< caution >}}
+ Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya
+ dengan SANs yang dibutuhkan untuk Node _control plane_ yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja,
+ pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan.
+ {{< /caution >}}
+
+5. Lalu, pada setiap Node _control plane_ yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan `kubeadm join`.
+ Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori _home_ ke `/etc/kubernetes/pki`:
+
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ mkdir -p /etc/kubernetes/pki/etcd
+ mv /home/${USER}/ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/sa.pub /etc/kubernetes/pki/
+ mv /home/${USER}/sa.key /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
+ ```
+
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index c81e9f41ec..adcf73db77 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -11,7 +11,7 @@ card:
Laman ini menunjukkan cara untuk menginstal `kubeadm`.
-Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
@@ -132,14 +132,14 @@ Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berh
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{% tab name="sistem operasi lainnya" %}}
Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container.
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{< /tabs >}}
@@ -174,7 +174,7 @@ Hal ini karena kubeadm dan Kubernetes membutuhkan
Untuk informasi lebih lanjut mengenai _version skew_, lihat:
* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
+* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian atau HypriotOS" %}}
@@ -304,4 +304,4 @@ Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyel
## {{% heading "whatsnext" %}}
-* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
+* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md
index 148f402402..6a575ad8f1 100644
--- a/content/id/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md
@@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda
Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`,
yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver.
-Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/).
+Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/).
Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut,
di `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes:
- dapat digunakan untuk menjangkau Node, Pod, atau Service
- melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service
-1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- berjalan di setiap Node
- memproksi UDP dan TCP
diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index b2b80aacba..8775823304 100644
--- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -320,7 +320,7 @@ contexts:
```
Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat
-[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
## Jelajahi direktori $HOME/.kube
@@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 1c6226b1be..d6d04df2ad 100644
--- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -19,7 +19,7 @@ _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigura
Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan
servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
-silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
+silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/)
@@ -35,7 +35,7 @@ silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
## Berkas konfigurasi
Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
-[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu:
```yaml
type: LoadBalancer
diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..f2140e5276
--- /dev/null
+++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,129 @@
+---
+title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster
+content_type: task
+weight: 100
+---
+
+
+
+Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container
+untuk Pod yang berjalan dalam sebuah klaster.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang
+berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar
+Container untuk masing-masing Pod.
+
+## Membuat daftar semua _image_ Container pada semua Namespace
+
+- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces`
+- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container
+ dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_
+ `image` dari keluaran json yang dihasilkan.
+ - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/)
+ untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`.
+- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq`
+ - Gunakan `tr` untuk mengganti spasi dengan garis baru
+ - Gunakan `sort` untuk menyortir hasil
+ - Gunakan `uniq` untuk mengumpulkan jumlah _image_
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image`
+dari semua poin yang dikembalikan.
+
+Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_
+di dalam Pod. Hal ini memastikan _field_ yang diambil benar
+bahkan ketika nama _field_ tersebut diulangi,
+misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+`Jsonpath` dapat diartikan sebagai berikut:
+
+- `.items[*]`: untuk setiap nilai yang dihasilkan
+- `.spec`: untuk mendapatkan spesifikasi
+- `.containers[*]`: untuk setiap Container
+- `.image`: untuk mendapatkan _image_
+
+{{< note >}}
+Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`,
+bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod
+sebagai keluarannya, bukan daftar dari semua Pod.
+
+{{< /note >}}
+
+## Membuat daftar _image_ Container berdasarkan Pod
+
+Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk
+melakukan iterasi untuk setiap elemen secara individual.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Membuat daftar _image_ yang difilter berdasarkan label dari Pod
+
+Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter
+dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod
+
+Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter
+dibawah ini hanya menyaring Pod pada Namespace `kube-system`.
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
+
+Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/)
+untuk memformat keluaran seperti berikut:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Referensi
+
+* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/).
+* Referensi panduan [Go template](https://golang.org/pkg/text/template/).
+
+
+
+
diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
index a83605db40..99d23c823d 100644
--- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai.
_Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
-- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
+- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan.
-- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
+- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
- **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif.
- Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
+ Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
-- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal.
@@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan:
-- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
+- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
-- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
+- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
Contoh:
@@ -107,9 +107,9 @@ track=stable
Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih.
-- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/).
+- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/).
- Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
+ Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih.
@@ -123,7 +123,7 @@ track=stable
### Menggungah berkas YAML atau JSON
-Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/).
+Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/).
Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard.
diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md
new file mode 100644
index 0000000000..0b2ebea7fe
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md
@@ -0,0 +1,177 @@
+---
+title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability)
+content_type: task
+---
+
+
+
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
+
+Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE).
+Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Memulai klaster yang kompatibel dengan HA
+
+Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`:
+
+* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server.
+Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan.
+
+* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru.
+Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd.
+Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat.
+
+Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat.
+Atur tanda berikut:
+
+* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan.
+
+Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b:
+
+```shell
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+```
+
+Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_;
+Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya.
+
+
+## Menambahkan replika _control plane_ yang baru
+
+Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana.
+Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini:
+
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan.
+Region ini harus sama dengan region dari zona replika yang lain.
+
+Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`,
+karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA.
+
+Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA:
+
+```shell
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Menghapus replika _control plane_
+
+Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut:
+
+* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus.
+
+* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus.
+Jika kosong: replika mana saja dari zona yang diberikan akan dihapus.
+
+Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+```
+
+## Mengatasi replika _control plane_ yang gagal
+
+Jika salah satu replika _control plane_ di klaster HA kamu gagal,
+praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama.
+Berikut ini contoh perintah yang menunjukkan proses tersebut:
+
+1. Menghapus replika yang gagal:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
+
+2. Menambahkan replika baru untuk menggantikan replika yang lama
+
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA
+
+* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula.
+Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain
+(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail).
+
+* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten.
+Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas.
+Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal.
+
+* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru.
+Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya.
+Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang).
+
+
+
+
+
+## Catatan implementasi
+
+
+
+### Ikhtisar
+
+Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut:
+
+* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus;
+
+* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia;
+
+* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster;
+
+* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi.
+
+Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka.
+
+
+### Penyeimbang Beban
+
+Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat
+dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban.
+Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada.
+Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan.
+
+
+### Service _control plane_ & kubelet
+
+Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes,
+sistem akan mengarahkan semua lalu lintas ke IP eksternal:
+
+* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal.
+
+* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_.
+
+Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_.
+
+
+### Sertifikat _control plane_
+
+Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika.
+Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika;
+Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS.
+
+### Pengklasteran etcd
+
+Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster).
+Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL.
+
+## Bacaan tambahan
+
+[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
+
+
diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md
new file mode 100644
index 0000000000..409e42dd70
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/namespaces.md
@@ -0,0 +1,302 @@
+---
+title: Membagi sebuah Klaster dengan Namespace
+content_type: task
+---
+
+
+Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu.
+
+
+## {{% heading "prerequisites" %}}
+
+* Memiliki [Klaster Kubernetes](/id/docs/setup/).
+* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes.
+
+
+
+
+## Melihat Namespace
+
+1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan:
+
+```shell
+kubectl get namespaces
+```
+```
+NAME STATUS AGE
+default Active 11d
+kube-system Active 11d
+kube-public Active 11d
+```
+
+Kubernetes mulai dengan tiga Namespace pertama:
+
+ * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain
+ * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes
+ * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan.
+
+Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan:
+
+```shell
+kubectl get namespaces
+```
+
+Atau kamu bisa mendapatkan informasi detail menggunakan:
+
+```shell
+kubectl describe namespaces
+```
+```
+Name: default
+Labels:
+Annotations:
+Status: Active
+
+No resource quota.
+
+Resource Limits
+ Type Resource Min Max Default
+ ---- -------- --- --- ---
+ Container cpu - - 100m
+```
+
+Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya.
+
+Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace.
+
+Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace.
+
+Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
+
+Sebuah Namespace dapat berada dalam salah satu dari dua buah fase:
+
+ * `Active` Namespace sedang digunakan
+ * `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru
+
+Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut.
+
+## Membuat sebuah Namespace baru
+
+{{< note >}}
+ Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes.
+{{< /note >}}
+
+1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini:
+
+ ```yaml
+ apiVersion: v1
+ kind: Namespace
+ metadata:
+ name:
+ ```
+ Then run:
+
+ ```
+ kubectl create -f ./my-namespace.yaml
+ ```
+
+2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini:
+
+ ```
+ kubectl create namespace
+ ```
+
+Nama Namespace kamu harus merupakan
+[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid.
+
+Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya.
+
+Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace.
+
+## Menghapus Namespace
+
+Hapus Namespace dengan
+
+```shell
+kubectl delete namespaces
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.
-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.
+
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html
index 6a930f945c..79ac9bf3a8 100644
--- a/content/en/case-studies/ocado/index.html
+++ b/content/en/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:
@@ -32,7 +32,7 @@ quote: >
CASE STUDY:
Ocado: Running Grocery Warehouses with a Cloud Native Platform
-
+
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 +
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with
+
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html
index 040f704efa..1b95ec5f35 100644
--- a/content/en/case-studies/openAI/index.html
+++ b/content/en/case-studies/openAI/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
css: /css/style_case_studies.css
---
-
+
CASE STUDY:
@@ -56,7 +56,7 @@ 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
+
-
+
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html
index ddb567afb3..78f70228e5 100644
--- a/content/en/case-studies/pearson/index.html
+++ b/content/en/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:
@@ -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."
- CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes
+
-
+
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html
index 637f891b3e..8d032c7a8b 100644
--- a/content/en/case-studies/pingcap/index.html
+++ b/content/en/case-studies/pingcap/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -52,7 +52,7 @@ featured: false
Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-
CASE STUDY:
PingCAP Bets on Cloud Native for Its TiDB Database Platform
@@ -52,7 +52,7 @@ featured: false
Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
+
-
+
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html
index 0aa2381aa1..e4be7031bb 100644
--- a/content/en/case-studies/pinterest/index.html
+++ b/content/en/case-studies/pinterest/index.html
@@ -11,7 +11,7 @@ quote: >
---
-
+
CASE STUDY:
@@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
-
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
+
-
+
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html
index 03bbc51173..2f0beda5ae 100644
--- a/content/en/case-studies/prowise/index.html
+++ b/content/en/case-studies/prowise/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
@@ -50,7 +50,7 @@ featured: false
The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
CASE STUDY:
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion
@@ -50,7 +50,7 @@ featured: false
The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
+
-
+
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html
index 62501c4f5b..2863ceac75 100644
--- a/content/en/case-studies/ricardo-ch/index.html
+++ b/content/en/case-studies/ricardo-ch/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -48,7 +48,7 @@ featured: false
To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
CASE STUDY:
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
@@ -48,7 +48,7 @@ featured: false
To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
+
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html index 4a99d28fb3..86ebe15f91 100644 --- a/content/en/case-studies/slamtec/index.html +++ b/content/en/case-studies/slamtec/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html index 4a99d28fb3..86ebe15f91 100644 --- a/content/en/case-studies/slamtec/index.html +++ b/content/en/case-studies/slamtec/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
- CASE STUDY:
+
-
+
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html
index a11527c2d9..349ed8c2de 100644
--- a/content/en/case-studies/slingtv/index.html
+++ b/content/en/case-studies/slingtv/index.html
@@ -11,7 +11,7 @@ quote: >
---
-
+
CASE STUDY:
@@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
-
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
+
-
+
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html
index 64708a20f8..becf486413 100644
--- a/content/en/case-studies/sos/index.html
+++ b/content/en/case-studies/sos/index.html
@@ -8,7 +8,7 @@ logo: sos_featured_logo.png
---
-
+
CASE STUDY:
@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
CASE STUDY:
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
+
-
+
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html
index 85e7fc1e86..63243b08f6 100644
--- a/content/en/case-studies/spotify/index.html
+++ b/content/en/case-studies/spotify/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
-
+
-
+
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html
index d2b2a18c92..27340835f4 100644
--- a/content/en/case-studies/squarespace/index.html
+++ b/content/en/case-studies/squarespace/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
css: /css/style_case_studies.css
---
-
+
CASE STUDY:
@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
CASE STUDY:
Squarespace: Gaining Productivity and Resilience with Kubernetes
@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
+
-
+
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html
index 0a35de2b1a..ad990356ff 100644
--- a/content/en/case-studies/thredup/index.html
+++ b/content/en/case-studies/thredup/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -49,7 +49,7 @@ featured: false
"We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
- CASE STUDY:
+
-
+
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html
index 4ca7aa1bbc..c2ac2a2a72 100644
--- a/content/en/case-studies/vsco/index.html
+++ b/content/en/case-studies/vsco/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -48,7 +48,7 @@ featured: false
-
CASE STUDY:
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
@@ -48,7 +48,7 @@ featured: false
+
-
+
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html
index aa41b7cb44..fbb86bdd24 100644
--- a/content/en/case-studies/woorank/index.html
+++ b/content/en/case-studies/woorank/index.html
@@ -8,7 +8,7 @@ featured: false
---
-
+
CASE STUDY:
@@ -50,7 +50,7 @@ featured: false
-
CASE STUDY:
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with
12 Engineers—At 30% Less Cost
@@ -50,7 +50,7 @@ featured: false
12 Engineers—At 30% Less Cost
+
-
+
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html
index 95f323d5ae..1c09503bfb 100644
--- a/content/en/case-studies/workiva/index.html
+++ b/content/en/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:
@@ -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.
- +
-
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
+
-
-
+
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
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
+
@@ -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 diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/en/case-studies/ygrene/index.html +++ b/content/en/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. --- -
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 diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/en/case-studies/ygrene/index.html +++ b/content/en/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:
@@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
-
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
+
-
+
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
index 39af4fb779..c3b51f3acf 100644
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -64,7 +64,7 @@ Before choosing a guide, here are some considerations:
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
### Securing the kubelet
- * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
+ * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index 26fc1194df..5cdd070e0f 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -303,6 +303,9 @@ to get a mapping of UIDs to names for both FlowSchemas and
PriorityLevelConfigurations.
## Observability
+
+### Metrics
+
When you enable the API Priority and Fairness feature, the kube-apiserver
exports additional metrics. Monitoring these can help you determine whether your
configuration is inappropriately throttling important traffic, or find
@@ -365,9 +368,65 @@ poorly-behaved workloads that may be harming system health.
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
+### Debug endpoints
+When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports.
+- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
+ workload-low, 0, true, false, 0, 0,
+ global-default, 0, true, false, 0, 0,
+ exempt, , , , , ,
+ catch-all, 0, true, false, 0, 0,
+ system, 0, true, false, 0, 0,
+ leader-election, 0, true, false, 0, 0,
+ workload-high, 0, true, false, 0, 0,
+ ```
+- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_queues
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart,
+ workload-high, 0, 0, 0, 0.0000,
+ workload-high, 1, 0, 0, 0.0000,
+ workload-high, 2, 0, 0, 0.0000,
+ ...
+ leader-election, 14, 0, 0, 0.0000,
+ leader-election, 15, 0, 0, 0.0000,
+ ```
+
+- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_requests
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime,
+ exempt, , , , , ,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
+ ```
+
+ In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation.
+
+ You can get a more detailed listing with a command like this:
+ ```shell
+ kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ ```
+
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index b052dd3a15..d0485a4342 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
kubectl scale deployment/my-nginx --replicas=1
```
```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
```
Now you only have one pod managed by the deployment.
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 29044be250..6779ee984a 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -12,7 +12,7 @@ understand exactly how it is expected to work. There are 4 distinct networking
problems to address:
1. Highly-coupled container-to-container communications: this is solved by
- [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications.
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications.
2. Pod-to-Pod communications: this is the primary focus of this document.
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 89a361a350..f40c99fbc4 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -224,7 +224,7 @@ data has the following advantages:
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
closing watches for config maps marked as immutable.
-To use this feature, enable the `ImmutableEmphemeralVolumes`
+To use this feature, enable the `ImmutableEphemeralVolumes`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
your Secret or ConfigMap `immutable` field to `true`. For example:
```yaml
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index db78a8304e..f791510b39 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -132,11 +132,9 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
+ - name: app
+ image: images.my-company.example/app:v4
env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
resources:
requests:
memory: "64Mi"
@@ -144,8 +142,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -330,18 +328,15 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
- env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
+ - name: app
+ image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 7eae77ac46..01e1f64d19 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -217,7 +217,7 @@ makes Pod P eligible to preempt Pods on another Node.
#### Graceful termination of preemption victims
When Pods are preempted, the victims get their
-[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
They have that much time to finish their work and exit. If they don't, they are
killed. This graceful termination period creates a time gap between the point
that the scheduler preempts Pods and the time when the pending Pod (P) can be
@@ -230,7 +230,7 @@ priority Pods to zero or a small number.
#### PodDisruptionBudget is supported, but not guaranteed
-A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/)
+A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
allows application owners to limit the number of Pods of a replicated application
that are down simultaneously from voluntary disruptions. Kubernetes supports
PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index 386e4d00bb..c8e93e93db 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
### Hook handler implementations
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index a01e8d84f9..415d920b40 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -129,7 +129,7 @@ example, run these on your desktop/laptop:
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
-For production clusers, use a configuration management tool so that you can apply this
+For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
deleted file mode 100644
index 7f81439c41..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Poseidon-Firmament Scheduler
-content_type: concept
-weight: 80
----
-
-
-
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-
-
-
-
-
-
-## Introduction
-
-Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions.
-
-Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements.
-
-Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers.
-
-Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages:
-
-- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale.
- The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs).
-- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads.
-- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run.
-- The Poseidon-Firmament scheduler supports scheduling complex rule constraints.
-
-## How the Poseidon-Firmament scheduler works
-
-Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-...
-spec:
- schedulerName: poseidon
-...
-```
-
-## Batch scheduling
-
-As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs.
-
-Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most:
-
-1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous.
-2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs).
-
-## Feature state
-
-Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases.
-
-{{< caution >}}
-Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail.
-{{< /caution >}}
-
-## Feature comparison {#feature-comparison-matrix}
-
-{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}}
-|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes|
-|--- |--- |--- |--- |
-|Node Affinity/Anti-Affinity|Y|Y||
-|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.|
-|Taints & Tolerations|Y|Y||
-|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.|
-|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.|
-|Colocation Interference Avoidance|N|N||
-|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.|
-|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.|
-|Gang Scheduling|N|Y||
-|Support for Pre-bound Persistence Volume Scheduling|Y|Y||
-|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N||
-|High Availability|Y|N||
-|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.|
-|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.|
-|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y||
-{{< /table >}}
-
-## Installation
-
-The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster.
-
-## Performance comparison
-
-{{< note >}}
- Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler.
-{{< /note >}}
-
-Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks:
-
-1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed.
-2. There is limited opportunities for amortizing work across pods because they are considered for placement individually.
-
-These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-
-
-## {{% heading "whatsnext" %}}
-
-* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
-* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
-* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
-* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index b3b6960358..42d12425b7 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -25,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-
-
## API changes
@@ -87,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Versioning is done at the API level rather than at the resource or field level to ensure that the
API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -157,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 1f4f4e7509..ab447cdcd6 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 0f2965a7a3..9829692126 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup
Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 4d3a9255d4..d7fc53a4d0 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -235,7 +235,7 @@ IngressClass resource will ensure that new Ingresses without an If you have more than one IngressClass marked as the default for your cluster, the admission controller prevents creating new Ingress objects that don't have an `ingressClassName` specified. You can resolve this by ensuring that at most 1 -IngressClasess are marked as default in your cluster. +IngressClasses are marked as default in your cluster. {{< /caution >}} ## Types of Ingress diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 79d260d52a..9819334ce8 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1356,7 +1356,7 @@ persistent volume: of a volume. This map must correspond to the map returned in the `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The map is passed to the CSI driver via the `volume_attributes` field in the + The map is passed to the CSI driver via the `volume_context` field in the `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. - `controllerPublishSecretRef`: A reference to the secret object containing diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 7f1b5c4630..c3d8cf36d8 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev The `.spec.template` is one of the required fields in `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 67582e9041..2c2fd8c7c2 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -13,8 +13,8 @@ weight: 30 -A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and -[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). +A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} +{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. @@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th {{< /note >}} - - ## Use Case @@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib The `.spec.template` and `.spec.selector` are the only required field of the `.spec`. -The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an -`apiVersion` or `kind`. +The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)). @@ -1155,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). -### Rollback To - -Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used. - ### Revision History Limit A Deployment's revision history is stored in the ReplicaSets it controls. diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index a20951a35e..79cc905f58 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy` field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan", "Foreground", or "Background". -Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`. -This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and -Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you -specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` -group version, dependent objects are deleted by default. - Here's an example that deletes dependents in background: ```shell diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 21e8aceb64..81c1280943 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index 2cc8284940..d59c09fc6b 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector). diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 index a105f18fb3..c7408721b7 --- a/content/en/docs/concepts/workloads/pods/_index.md +++ b/content/en/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,271 @@ --- -title: "Pods" +reviewers: +- erictune +title: Pods +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + + +_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes. + +A _Pod_ (as in a pod of whales or pea pod) is a group of one or more +{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification +for how to run the containers. A Pod's contents are always co-located and +co-scheduled, and run in a shared context. A Pod models an +application-specific "logical host": it contains one or more application +containers which are relatively tightly coupled. +In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. + +As well as application containers, a Pod can contain +[init containers](/docs/concepts/workloads/pods/init-containers/) that run +during Pod startup. You can also inject +[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) +for debugging if your cluster offers this. + + + +## What is a Pod? + +{{< note >}} +While Kubernetes supports more +{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} +than just Docker, [Docker](https://www.docker.com/) is the most commonly known +runtime, and it helps to describe Pods using some terminology from Docker. +{{< /note >}} + +The shared context of a Pod is a set of Linux namespaces, cgroups, and +potentially other facets of isolation - the same things that isolate a Docker +container. Within a Pod's context, the individual applications may have +further sub-isolations applied. + +In terms of Docker concepts, a Pod is similar to a group of Docker containers +with shared namespaces and shared filesystem volumes. + +## Using Pods + +Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment" +term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}. +If your Pods need to track state, consider the +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource. + +Pods in a Kubernetes cluster are used in two main ways: + +* **Pods that run a single container**. The "one-container-per-Pod" model is the + most common Kubernetes use case; in this case, you can think of a Pod as a + wrapper around a single container; Kubernetes manages Pods rather than managing + the containers directly. +* **Pods that run multiple containers that need to work together**. A Pod can + encapsulate an application composed of multiple co-located containers that are + tightly coupled and need to share resources. These co-located containers + form a single cohesive unit of service—for example, one container serving data + stored in a shared volume to the public, while a separate _sidecar_ container + refreshes or updates those files. + The Pod wraps these containers, storage resources, and an ephemeral network + identity together as a single unit. + + {{< note >}} + Grouping multiple co-located and co-managed containers in a single Pod is a + relatively advanced use case. You should use this pattern only in specific + instances in which your containers are tightly coupled. + {{< /note >}} + +Each Pod is meant to run a single instance of a given application. If you want to +scale your application horizontally (to provide more overall resources by running +more instances), you should use multiple Pods, one for each instance. In +Kubernetes, this is typically referred to as _replication_. +Replicated Pods are usually created and managed as a group by a workload resource +and its {{< glossary_tooltip text="controller" term_id="controller" >}}. + +See [Pods and controllers](#pods-and-controllers) for more information on how +Kubernetes uses workload resources, and their controllers, to implement application +scaling and auto-healing. + +### How Pods manage multiple containers + +Pods are designed to support multiple cooperating processes (as containers) that form +a cohesive unit of service. The containers in a Pod are automatically co-located and +co-scheduled on the same physical or virtual machine in the cluster. The containers +can share resources and dependencies, communicate with one another, and coordinate +when and how they are terminated. + +For example, you might have a container that +acts as a web server for files in a shared volume, and a separate "sidecar" container +that updates those files from a remote source, as in the following diagram: + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. + +Pods natively provide two kinds of shared resources for their constituent containers: +[networking](#pod-networking) and [storage](#pod-storage). + +## Working with Pods + +You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This +is because Pods are designed as relatively ephemeral, disposable entities. When +a Pod gets created (directly by you, or indirectly by a +{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is +scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. +The Pod remains on that node until the Pod finishes execution, the Pod object is deleted, +the Pod is *evicted* for lack of resources, or the node fails. + +{{< note >}} +Restarting a container in a Pod should not be confused with restarting a Pod. A Pod +is not a process, but an environment for running container(s). A Pod persists until +it is deleted. +{{< /note >}} + +When you create the manifest for a Pod object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Pods and controllers + +You can use workload resources to create and manage multiple Pods for you. A controller +for the resource handles replication and rollout and automatic healing in case of +Pod failure. For example, if a Node fails, a controller notices that Pods on that +Node have stopped working and creates a replacement Pod. The scheduler places the +replacement Pod onto a healthy Node. + +Here are some examples of workload resources that manage one or more Pods: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod templates + +Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods +from a _pod template_ and manage those Pods on your behalf. + +PodTemplates are specifications for creating Pods, and are included in workload resources such as +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Each controller for a workload resource uses the `PodTemplate` inside the workload +object to make actual Pods. The `PodTemplate` is part of the desired state of whatever +workload resource you used to run your app. + +The sample below is a manifest for a simple Job with a `template` that starts one +container. The container in that Pod prints a message then pauses. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # This is the pod template + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # The pod template ends here +``` + +Modifying the pod template or switching to a new pod template has no effect on the +Pods that already exist. Pods do not receive template updates directly. Instead, +a new Pod is created to match the revised pod template. + +For example, the deployment controller ensures that the running Pods match the current +pod template for each Deployment object. If the template is updated, the Deployment has +to remove the existing Pods and create new Pods based on the updated template. Each workload +resource implements its own rules for handling changes to the Pod template. + +On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not +directly observe or manage any of the details around pod templates and updates; those +details are abstracted away. That abstraction and separation of concerns simplifies +system semantics, and makes it feasible to extend the cluster's behavior without +changing existing code. + +## Resource sharing and communication + +Pods enable data sharing and communication among their constituent +containters. + +### Storage in Pods {#pod-storage} + +A Pod can specify a set of shared storage +{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers +in the Pod can access the shared volumes, allowing those containers to +share data. Volumes also allow persistent data in a Pod to survive +in case one of the containers within needs to be restarted. See +[Storage](/docs/concepts/storage/) for more information on how +Kubernetes implements shared storage and makes it available to Pods. + +### Pod networking + +Each Pod is assigned a unique IP address for each address family. Every +container in a Pod shares the network namespace, including the IP address and +network ports. Inside a Pod (and **only** then), the containers that belong to the Pod +can communicate with one another using `localhost`. When containers in a Pod communicate +with entities *outside the Pod*, +they must coordinate how they use the shared network resources (such as ports). +Within a Pod, containers share an IP address and port space, and +can find each other via `localhost`. The containers in a Pod can also communicate +with each other using standard inter-process communications like SystemV semaphores +or POSIX shared memory. Containers in different Pods have distinct IP addresses +and can not communicate by IPC without +[special configuration](/docs/concepts/policy/pod-security-policy/). +Containers that want to interact with a container running in a different Pod can +use IP networking to comunicate. + +Containers within the Pod see the system hostname as being the same as the configured +`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) +section. + +## Privileged mode for containers + +Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. +Processes within a privileged container get almost the same privileges that are available to processes outside a container. + +{{< note >}} +Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. +{{< /note >}} + +## Static Pods + +_Static Pods_ are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Whereas most Pods are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static +Pods, the kubelet directly supervises each static Pod (and restarts it if it fails). + +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +The main use for static Pods is to run a self-hosted control plane: in other words, +using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components). + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. + +## {{% heading "whatsnext" %}} + +* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). +* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/). +* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to + configure different Pods with different container runtime configurations. +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. +* Pod is a top-level resource in the Kubernetes REST API. + The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + object definition describes the object in detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container. + +To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including: + * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 589bde5668..0810b6fec7 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -11,17 +11,15 @@ weight: 60 This guide is for application owners who want to build highly available applications, and thus need to understand -what types of Disruptions can happen to Pods. +what types of disruptions can happen to Pods. -It is also for Cluster Administrators who want to perform automated +It is also for cluster administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. - - -## Voluntary and Involuntary Disruptions +## Voluntary and involuntary disruptions Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error. @@ -48,7 +46,7 @@ Administrator. Typical application owner actions include: - updating a deployment's pod template causing a restart - directly deleting a pod (e.g. by accident) -Cluster Administrator actions include: +Cluster administrator actions include: - [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade. - Draining a node from a cluster to scale the cluster down (learn about @@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa deleting deployments or pods bypasses Pod Disruption Budgets. {{< /caution >}} -## Dealing with Disruptions +## Dealing with disruptions Here are some ways to mitigate involuntary disruptions: @@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. -Kubernetes offers features to help run highly available applications at the same -time as frequent voluntary disruptions. We call this set of features -*Disruption Budgets*. - -## How Disruption Budgets Work +## Pod disruption budgets {{< feature-state for_k8s_version="v1.5" state="beta" >}} -An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. -A PDB limits the number of pods of a replicated application that are down simultaneously from -voluntary disruptions. For example, a quorum-based application would +Kubernetes offers features to help you run highly available applications even when you +introduce frequent voluntary disruptions. + +As an application owner, you can create a PodDisruptionBudget (PDB) for each application. +A PDB limits the number of Pods of a replicated application that are down simultaneously from +voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) -instead of directly deleting pods or deployments. Examples are the `kubectl drain` command -and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`). +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +instead of directly deleting pods or deployments. -When a cluster administrator wants to drain a node -they use the `kubectl drain` command. That tool tries to evict all -the pods on the machine. The eviction request may be temporarily rejected, -and the tool periodically retries all failed requests until all pods -are terminated, or until a configurable timeout is reached. +For example, the `kubectl drain` subcommand lets you mark a node as going out of +service. When you run `kubectl drain`, the tool tries to evict all of the Pods on +the Node you're taking out of service. The eviction request that `kubectl` submits on +your behalf may be temporarily rejected, so the tool periodically retries all failed +requests until all Pods on the target node are terminated, or until a configurable timeout +is reached. A PDB specifies the number of replicas that an application can tolerate having, relative to how many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, -then the Eviction API will allow voluntary disruption of one, but not two pods, at a time. +then the Eviction API will allow voluntary disruption of one (but not two) pods at a time. The group of pods that comprise the application is specified using a label selector, the same as the one used by the application's controller (deployment, stateful-set, etc). -The "intended" number of pods is computed from the `.spec.replicas` of the pods controller. -The controller is discovered from the pods using the `.metadata.ownerReferences` of the object. +The "intended" number of pods is computed from the `.spec.replicas` of the workload resource +that is managing those pods. The control plane discovers the owning workload resource by +examining the `.metadata.ownerReferences` of the Pod. PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from occurring, but they do count against the budget. Pods which are deleted or unavailable due to a rolling upgrade to an application do count -against the disruption budget, but controllers (like deployment and stateful-set) -are not limited by PDBs when doing rolling upgrades -- the handling of failures -during application updates is configured in the controller spec. -(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +against the disruption budget, but workload resources (such as Deployment and StatefulSet) +are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures +during application updates is configured in the spec for the specific workload resource. -When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) +When a pod is evicted using the eviction API, it is gracefully +[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the +`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) -## PDB Example +## PodDisruptionBudget example {#pdb-example} Consider a cluster with 3 nodes, `node-1` through `node-3`. The cluster is running several applications. One of them has 3 replicas initially called @@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) +* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + including steps to maintain its availability during the rollout. diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index d72265faf5..2b292d376d 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,16 +6,60 @@ weight: 30 -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} - -This page describes the lifecycle of a Pod. +This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting +in the `Pending` [phase](#pod-phase), moving through `Running` if at least one +of its primary containers starts OK, and then through either the `Succeeded` or +`Failed` phases depending on whether any container in the Pod terminated in failure. +Whilst a Pod is running, the kubelet is able to restart containers to handle some +kind of faults. Within a Pod, Kubernetes tracks different container +[states](#container-states) and handles +In the Kubernetes API, Pods have both a specification and an actual status. The +status for a Pod object consists of a set of [Pod conditions](#pod-conditions). +You can also inject [custom readiness information](#pod-readiness-gate) into the +condition data for a Pod, if that is useful to your application. +Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime. +Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops +or is [terminated](#pod-termination). +## Pod lifetime + +Like individual application containers, Pods are considered to be relatively +ephemeral (rather than durable) entities. Pods are created, assigned a unique +ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled +to nodes where they remain until termination (according to restart policy) or +deletion. +If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node +are [scheduled for deletion](#pod-garbage-collection) after a timeout period. + +Pods do not, by themselves, self-heal. If a Pod is scheduled to a +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, +or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a +higher-level abstraction, called a +{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of +managing the relatively disposable Pod instances. + +A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, +that Pod can be replaced by a new, near-identical Pod, with even the same name i +desired, but with a different UID. + +When something is said to have the same lifetime as a Pod, such as a +{{< glossary_tooltip term_id="volume" text="volume" >}}, +that means that the thing exists as long as that specific Pod (with that exact UID) +exists. If that Pod is deleted for any reason, and even if an identical replacement +is created, the related thing (a volume, in this example) is also destroyed and +created anew. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*A multi-container Pod that contains a file puller and a +web server that uses a persistent volume for shared storage between the containers.* + ## Pod phase A Pod's `status` field is a @@ -24,7 +68,7 @@ object, which has a `phase` field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations -of Container or Pod state, nor is it intended to be a comprehensive state machine. +of container or Pod state, nor is it intended to be a comprehensive state machine. The number and meanings of Pod phase values are tightly guarded. Other than what is documented here, nothing should be assumed about Pods that @@ -34,188 +78,106 @@ Here are the possible values for `phase`: Value | Description :-----|:----------- -`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting. -`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted. -`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system. -`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod. +`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network. +`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. +`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. +`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. +`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Container states + +As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of +each container inside a Pod. You can use +[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to +trigger events to run at certain points in a container's lifecycle. + +Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} +assigns a Pod to a Node, the kubelet starts creating containers for that Pod +using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +There are three possible container states: `Waiting`, `Running`, and `Terminated`. + +To the check state of a Pod's containers, you can use +`kubectl describe pod`. The output shows the state for each container
+within that Pod.
+
+Each state has a specific meaning:
+
+### `Waiting` {#container-state-waiting}
+
+If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+A container in the `Waiting` state is still running the operations it requires in
+order to complete start up: for example, pulling the container image from a container
+image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
+data.
+When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see
+a Reason field to summarize why the container is in that state.
+
+### `Running` {#container-state-running}
+
+The `Running` status indicates that a container is executing without issues. If there
+was a `postStart` hook configured, it has already executed and executed. When you use
+`kubectl` to query a Pod with a container that is `Running`, you also see information
+about when the container entered the `Running` state.
+
+### `Terminated` {#container-state-terminated}
+
+A container in the `Terminated` state has begin execution and has then either run to
+completion or has failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, and exit code, and the start and
+finish time for that container's period of execution.
+
+If a container has a `preStop` hook configured, that runs before the container enters
+the `Terminated` state.
+
+## Container restart policy {#restart-policy}
+
+The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure,
+and Never. The default value is Always.
+
+The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
+refers to restarts of the containers by the kubelet on the same node. After containers
+in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
+40s, …), that is capped at five minutes. Once a container has executed with no problems
+for 10 minutes without any problems, the kubelet resets the restart backoff timer for
+that container.
## Pod conditions
A Pod has a PodStatus, which has an array of
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)
-through which the Pod has or has not passed. Each element of the PodCondition
-array has six possible fields:
+through which the Pod has or has not passed:
-* The `lastProbeTime` field provides a timestamp for when the Pod condition
- was last probed.
+* `PodScheduled`: the Pod has been scheduled to a node.
+* `ContainersReady`: all containers in the Pod are ready.
+* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
+ have started successfully.
+* `Ready`: the Pod is able to serve requests and should be added to the load
+ balancing pools of all matching Services.
-* The `lastTransitionTime` field provides a timestamp for when the Pod
- last transitioned from one status to another.
-
-* The `message` field is a human-readable message indicating details
- about the transition.
-
-* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition.
-
-* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`".
-
-* The `type` field is a string with the following possible values:
-
- * `PodScheduled`: the Pod has been scheduled to a node;
- * `Ready`: the Pod is able to serve requests and should be added to the load
- balancing pools of all matching Services;
- * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
- have started successfully;
- * `ContainersReady`: all containers in the Pod are ready.
+Field name | Description
+:--------------------|:-----------
+`type` | Name of this Pod condition.
+`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`".
+`lastProbeTime` | Timestamp of when the Pod condition was last probed.
+`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another.
+`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition.
+`message` | Human-readable message indicating details about the last status transition.
-
-## Container probes
-
-A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
-on a Container. To perform a diagnostic,
-the kubelet calls a
-[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
-the Container. There are three types of handlers:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
- Executes a specified command inside the Container. The diagnostic
- is considered successful if the command exits with a status code of 0.
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
- Performs a TCP check against the Container's IP address on
- a specified port. The diagnostic is considered successful if the port is open.
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
- Performs an HTTP Get request against the Container's IP
- address on a specified port and path. The diagnostic is considered successful
- if the response has a status code greater than or equal to 200 and less than 400.
-
-Each probe has one of three results:
-
-* Success: The Container passed the diagnostic.
-* Failure: The Container failed the diagnostic.
-* Unknown: The diagnostic failed, so no action should be taken.
-
-The kubelet can optionally perform and react to three kinds of probes on running
-Containers:
-
-* `livenessProbe`: Indicates whether the Container is running. If
- the liveness probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a liveness probe, the default state is `Success`.
-
-* `readinessProbe`: Indicates whether the Container is ready to service requests.
- If the readiness probe fails, the endpoints controller removes the Pod's IP
- address from the endpoints of all Services that match the Pod. The default
- state of readiness before the initial delay is `Failure`. If a Container does
- not provide a readiness probe, the default state is `Success`.
-
-* `startupProbe`: Indicates whether the application within the Container is started.
- All other probes are disabled if a startup probe is provided, until it succeeds.
- If the startup probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a startup probe, the default state is `Success`.
-
-### When should you use a liveness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If the process in your Container is able to crash on its own whenever it
-encounters an issue or becomes unhealthy, you do not necessarily need a liveness
-probe; the kubelet will automatically perform the correct action in accordance
-with the Pod's `restartPolicy`.
-
-If you'd like your Container to be killed and restarted if a probe fails, then
-specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
-
-### When should you use a readiness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If you'd like to start sending traffic to a Pod only when a probe succeeds,
-specify a readiness probe. In this case, the readiness probe might be the same
-as the liveness probe, but the existence of the readiness probe in the spec means
-that the Pod will start without receiving any traffic and only start receiving
-traffic after the probe starts succeeding.
-If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe.
-
-If you want your Container to be able to take itself down for maintenance, you
-can specify a readiness probe that checks an endpoint specific to readiness that
-is different from the liveness probe.
-
-Note that if you just want to be able to drain requests when the Pod is deleted,
-you do not necessarily need a readiness probe; on deletion, the Pod automatically
-puts itself into an unready state regardless of whether the readiness probe exists.
-The Pod remains in the unready state while it waits for the Containers in the Pod
-to stop.
-
-### When should you use a startup probe?
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s.
-You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.
-
-For more information about how to set up a liveness, readiness, startup probe, see
-[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-## Pod and Container status
-
-For detailed information about Pod Container status, see
-[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
-and
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-Note that the information reported as Pod status depends on the current
-[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-
-## Container States
-
-Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod.
-
-* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information.
-
- ```yaml
- ...
- State: Waiting
- Reason: ErrImagePull
- ...
- ```
-
-* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state.
-
- ```yaml
- ...
- State: Running
- Started: Wed, 30 Jan 2019 16:46:38 +0530
- ...
- ```
-
-* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed.
-
- ```yaml
- ...
- State: Terminated
- Reason: Completed
- Exit Code: 0
- Started: Wed, 30 Jan 2019 11:45:26 +0530
- Finished: Wed, 30 Jan 2019 11:45:26 +0530
- ...
- ```
-
-## Pod readiness {#pod-readiness-gate}
+### Pod readiness {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
Your application can inject extra feedback or signals into PodStatus:
-_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify
-a list of additional conditions that the kubelet evaluates for Pod readiness.
+_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to
+specify a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
-fields for the Pod. If Kubernetes cannot find such a
-condition in the `status.conditions` field of a Pod, the status of the condition
+fields for the Pod. If Kubernetes cannot find such a condition in the
+`status.conditions` field of a Pod, the status of the condition
is defaulted to "`False`".
Here is an example:
@@ -258,152 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only*
when both the following statements apply:
* All containers in the Pod are ready.
-* All conditions specified in `ReadinessGates` are `True`.
+* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
-`False`, the kubelet sets the Pod's condition to `ContainersReady`.
+`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
-## Restart policy
+## Container probes
-A PodSpec has a `restartPolicy` field with possible values Always, OnFailure,
-and Never. The default value is Always.
-`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only
-refers to restarts of the Containers by the kubelet on the same node. Exited
-Containers that are restarted by the kubelet are restarted with an exponential
-back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten
-minutes of successful execution. As discussed in the
-[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
-once bound to a node, a Pod will never be rebound to another node.
+A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
+performed periodically by the [kubelet](/docs/admin/kubelet/)
+on a Container. To perform a diagnostic,
+the kubelet calls a
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
+the container. There are three types of handlers:
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+ Executes a specified command inside the container. The diagnostic
+ is considered successful if the command exits with a status code of 0.
-## Pod lifetime
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+ Performs a TCP check against the Pod's IP address on
+ a specified port. The diagnostic is considered successful if the port is open.
-In general, Pods remain until a human or
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+ Performs an HTTP `GET` request against the Pod's IP
+ address on a specified port and path. The diagnostic is considered successful
+ if the response has a status code greater than or equal to 200 and less than 400.
+
+Each probe has one of three results:
+
+* `Success`: The container passed the diagnostic.
+* `Failure`: The container failed the diagnostic.
+* `Unknown`: The diagnostic failed, so no action should be taken.
+
+The kubelet can optionally perform and react to three kinds of probes on running
+containers:
+
+* `livenessProbe`: Indicates whether the container is running. If
+ the liveness probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a liveness probe, the default state is `Success`.
+
+* `readinessProbe`: Indicates whether the container is ready to respond to requests.
+ If the readiness probe fails, the endpoints controller removes the Pod's IP
+ address from the endpoints of all Services that match the Pod. The default
+ state of readiness before the initial delay is `Failure`. If a Container does
+ not provide a readiness probe, the default state is `Success`.
+
+* `startupProbe`: Indicates whether the application within the container is started.
+ All other probes are disabled if a startup probe is provided, until it succeeds.
+ If the startup probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a startup probe, the default state is `Success`.
+
+For more information about how to set up a liveness, readiness, or startup probe,
+see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+
+### When should you use a liveness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If the process in your container is able to crash on its own whenever it
+encounters an issue or becomes unhealthy, you do not necessarily need a liveness
+probe; the kubelet will automatically perform the correct action in accordance
+with the Pod's `restartPolicy`.
+
+If you'd like your container to be killed and restarted if a probe fails, then
+specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
+
+### When should you use a readiness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If you'd like to start sending traffic to a Pod only when a probe succeeds,
+specify a readiness probe. In this case, the readiness probe might be the same
+as the liveness probe, but the existence of the readiness probe in the spec means
+that the Pod will start without receiving any traffic and only start receiving
+traffic after the probe starts succeeding.
+If your container needs to work on loading large data, configuration files, or
+migrations during startup, specify a readiness probe.
+
+If you want your container to be able to take itself down for maintenance, you
+can specify a readiness probe that checks an endpoint specific to readiness that
+is different from the liveness probe.
+
+{{< note >}}
+If you just want to be able to drain requests when the Pod is deleted, you do not
+necessarily need a readiness probe; on deletion, the Pod automatically puts itself
+into an unready state regardless of whether the readiness probe exists.
+The Pod remains in the unready state while it waits for the containers in the Pod
+to stop.
+{{< /note >}}
+
+### When should you use a startup probe?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Startup probes are useful for Pods that have containers that take a long time to
+come into service. Rather than set a long liveness interval, you can configure
+a separate configuration for probing the container as it starts up, allowing
+a time longer than the liveness interval would allow.
+
+If your container usually starts in more than
+`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a
+startup probe that checks the same endpoint as the liveness probe. The default for
+`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to
+allow the container to start, without changing the default values of the liveness
+probe. This helps to protect against deadlocks.
+
+## Termination of Pods {#pod-termination}
+
+Because Pods represent processes running on nodes in the cluster, it is important to
+allow those processes to gracefully terminate when they are no longer needed (rather
+than being abruptly stopped with a `KILL` signal and having no chance to clean up).
+
+The design aim is for you to be able to request deletion and know when processes
+terminate, but also be able to ensure that deletes eventually complete.
+When you request deletion of a Pod, the cluster records and tracks the intended grace period
+before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in
+place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
+shutdown.
+
+Typically, the container runtime sends a a TERM signal is sent to the main process in each
+container. Once the grace period has expired, the KILL signal is sent to any remainig
+processes, and the Pod is then deleted from the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
+container runtime's management service is restarted while waiting for processes to terminate, the
+cluster retries from the start including the full original grace period.
+
+An example flow:
+
+1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
+ (30 seconds).
+1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
+ along with the grace period.
+ If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
+ "Terminating".
+ On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
+ as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
+ shutdown process.
+ 1. If one of the Pod's containers has defined a `preStop`
+ [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
+ runs that hook inside of the container. If the `preStop` hook is still running after the
+ grace period expires, the kubelet requests a small, one-off grace period extension of 2
+ seconds.
+ {{< note >}}
+ If the `preStop` hook needs longer to complete than the default grace period allows,
+ you must modify `terminationGracePeriodSeconds` to suit this.
+ {{< /note >}}
+ 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
+ container.
+ {{< note >}}
+ The containers in the Pod receive the TERM signal at different times and in an arbitrary
+ order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
+ {{< /note >}}
+1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that
+ shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent
+ a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured
+ {{< glossary_tooltip text="selector" term_id="selector" >}}.
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources
+ no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly
+ cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from
+ the list of endpoints as soon as the termination grace period _begins_.
+1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends
+ `SIGKILL` to any processes still running in any container in the Pod.
+ The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
+1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
+ to 0 (immediate deletion).
+1. The API server deletes the Pod's API object, which is then no longer visible from any client.
+
+### Forced Pod termination {#pod-termination-forced}
+
+{{< caution >}}
+Forced deletions can be potentially disruptiove for some workloads and their Pods.
+{{< /caution >}}
+
+By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
+the `--grace-period=` option which allows you to override the default and specify your
+own value.
+
+Setting the grace period to `0` forcibly and immediately deletes the Pod from the API
+server. If the pod was still running on a node, that forcible deletion triggers the kubelet to
+begin immediate cleanup.
+
+{{< note >}}
+You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+{{< /note >}}
+
+When a force deletion is performed, the API server does not wait for confirmation
+from the kubelet that the Pod has been terminated on the node it was running on. It
+removes the Pod in the API immediately so a new Pod can be created with the same
+name. On the node, Pods that are set to terminate immediately will still be given
+a small grace period before being force killed.
+
+If you need to force-delete Pods that are part of a StatefulSet, refer to the task
+documentation for
+[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+
+### Garbage collection of failed Pods {#pod-garbage-collection}
+
+For failed Pods, the API objects remain in the cluster's API until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process
explicitly removes them.
+
The control plane cleans up terminated Pods (with a phase of `Succeeded` or
`Failed`), when the number of Pods exceeds the configured threshold
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
This avoids a resource leak as Pods are created and terminated over time.
-There are different kinds of resources for creating Pods:
-
-- Use a {{< glossary_tooltip term_id="deployment" >}},
- {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}}
- for Pods that are not expected to terminate, for example, web servers.
-
-- Use a {{< glossary_tooltip term_id="job" >}}
- for Pods that are expected to terminate once their work is complete;
- for example, batch computations. Jobs are appropriate only for Pods with
- `restartPolicy` equal to OnFailure or Never.
-
-- Use a {{< glossary_tooltip term_id="daemonset" >}}
- for Pods that need to run one per eligible node.
-
-All workload resources contain a PodSpec. It is recommended to create the
-appropriate workload resource and let the resource's controller create Pods
-for you, rather than directly create Pods yourself.
-
-If a node dies or is disconnected from the rest of the cluster, Kubernetes
-applies a policy for setting the `phase` of all Pods on the lost node to Failed.
-
-## Examples
-
-### Advanced liveness probe example
-
-Liveness probes are executed by the kubelet, so all requests are made in the
-kubelet network namespace.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- labels:
- test: liveness
- name: liveness-http
-spec:
- containers:
- - args:
- - /server
- image: k8s.gcr.io/liveness
- livenessProbe:
- httpGet:
- # when "host" is not defined, "PodIP" will be used
- # host: my-host
- # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
- # scheme: HTTPS
- path: /healthz
- port: 8080
- httpHeaders:
- - name: X-Custom-Header
- value: Awesome
- initialDelaySeconds: 15
- timeoutSeconds: 1
- name: liveness
-```
-
-### Example states
-
- * Pod is running and has one Container. Container exits with success.
- * Log completion event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Pod `phase` becomes Succeeded.
- * Never: Pod `phase` becomes Succeeded.
-
- * Pod is running and has one Container. Container exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has two Containers. Container 1 exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Do not restart Container; Pod `phase` stays Running.
- * If Container 1 is not running, and Container 2 exits:
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has one Container. Container runs out of memory.
- * Container terminates in failure.
- * Log OOM event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Log failure event; Pod `phase` becomes Failed.
-
- * Pod is running, and a disk dies.
- * Kill all Containers.
- * Log appropriate event.
- * Pod `phase` becomes Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
- * Pod is running, and its node is segmented out.
- * Node controller waits for timeout.
- * Node controller sets Pod `phase` to Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
-
-
## {{% heading "whatsnext" %}}
-
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
* Get hands-on experience
- [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-
+ [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
+* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+and
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
deleted file mode 100644
index e963b7ace6..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-reviewers:
-- erictune
-title: Pod Overview
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 60
----
-
-
-This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-
-
-
-
-## Understanding Pods
-
-A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
-
-A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
-
-[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
-
-
-Pods in a Kubernetes cluster can be used in two main ways:
-
-* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
-* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-
-Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_.
-Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}.
-See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing.
-
-### How Pods manage multiple containers
-
-Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
-
-Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
-
-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
-
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-
-Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
-
-#### Networking
-
-Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
-
-#### Storage
-
-A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
-
-## Working with Pods
-
-You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails.
-
-{{< note >}}
-Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted.
-{{< /note >}}
-
-Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller.
-
-### Pods and controllers
-
-You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node.
-
-Here are some examples of workload resources that manage one or more Pods:
-
-* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
-* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
-* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
-
-
-## Pod templates
-
-Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
-from a pod template and manage those Pods on your behalf.
-
-PodTemplates are specifications for creating Pods, and are included in workload resources such as
-[Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
-[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
-
-Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app.
-
-The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: hello
-spec:
- template:
- # This is the pod template
- spec:
- containers:
- - name: hello
- image: busybox
- command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
- restartPolicy: OnFailure
- # The pod template ends here
-```
-
-Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template.
-
-For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template.
-
-On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
-
-
-
-## {{% heading "whatsnext" %}}
-
-* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
-* Learn more about Pod behavior:
- * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 650280a82f..9982ac7240 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,7 +1,7 @@
---
title: Pod Topology Spread Constraints
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index d87dc92cb2..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-reviewers:
-title: Pods
-content_type: concept
-weight: 20
----
-
-
-
-_Pods_ are the smallest deployable units of computing that can be created and
-managed in Kubernetes.
-
-
-
-
-
-
-## What is a Pod?
-
-A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
-{{< glossary_tooltip text="containers" term_id="container" >}} (such as
-Docker containers), with shared storage/network, and a specification
-for how to run the containers. A Pod's contents are always co-located and
-co-scheduled, and run in a shared context. A Pod models an
-application-specific "logical host" - it contains one or more application
-containers which are relatively tightly coupled — in a pre-container
-world, being executed on the same physical or virtual machine would mean being
-executed on the same logical host.
-
-While Kubernetes supports more container runtimes than just Docker, Docker is
-the most commonly known runtime, and it helps to describe Pods in Docker terms.
-
-The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a Docker
-container. Within a Pod's context, the individual applications may have
-further sub-isolations applied.
-
-Containers within a Pod share an IP address and port space, and
-can find each other via `localhost`. They can also communicate with each
-other using standard inter-process communications like SystemV semaphores or
-POSIX shared memory. Containers in different Pods have distinct IP addresses
-and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
-These containers usually communicate with each other via Pod IP addresses.
-
-Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
-as part of a Pod and are made available to be mounted into each application's
-filesystem.
-
-In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
-a group of Docker containers with shared namespaces and shared filesystem
-volumes.
-
-Like individual application containers, Pods are considered to be relatively
-ephemeral (rather than durable) entities. As discussed in
-[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
-scheduled to nodes where they remain until termination (according to restart
-policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
-scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
-"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
-with even the same name if desired, but with a new UID (see [replication
-controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
-
-When something is said to have the same lifetime as a Pod, such as a volume,
-that means that it exists as long as that Pod (with that UID) exists. If that
-Pod is deleted for any reason, even if an identical replacement is created, the
-related thing (e.g. volume) is also destroyed and created anew.
-
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
-
-*A multi-container Pod that contains a file puller and a
-web server that uses a persistent volume for shared storage between the containers.*
-
-## Motivation for Pods
-
-### Management
-
-Pods are a model of the pattern of multiple cooperating processes which form a
-cohesive unit of service. They simplify application deployment and management
-by providing a higher-level abstraction than the set of their constituent
-applications. Pods serve as unit of deployment, horizontal scaling, and
-replication. Colocation (co-scheduling), shared fate (e.g. termination),
-coordinated replication, resource sharing, and dependency management are
-handled automatically for containers in a Pod.
-
-### Resource sharing and communication
-
-Pods enable data sharing and communication among their constituents.
-
-The applications in a Pod all use the same network namespace (same IP and port
-space), and can thus "find" each other and communicate using `localhost`.
-Because of this, applications in a Pod must coordinate their usage of ports.
-Each Pod has an IP address in a flat shared networking space that has full
-communication with other physical computers and Pods across the network.
-
-Containers within the Pod see the system hostname as being the same as the configured
-`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
-section.
-
-In addition to defining the application containers that run in the Pod, the Pod
-specifies a set of shared storage volumes. Volumes enable data to survive
-container restarts and to be shared among the applications within the Pod.
-
-## Uses of pods
-
-Pods can be used to host vertically integrated application stacks (e.g. LAMP),
-but their primary motivation is to support co-located, co-managed helper
-programs, such as:
-
-* content management systems, file and data loaders, local cache managers, etc.
-* log and checkpoint backup, compression, rotation, snapshotting, etc.
-* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
-* proxies, bridges, and adapters
-* controllers, managers, configurators, and updaters
-
-Individual Pods are not intended to run multiple instances of the same
-application, in general.
-
-For a longer explanation, see [The Distributed System ToolKit: Patterns for
-Composite
-Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
-
-## Alternatives considered
-
-_Why not just run multiple programs in a single (Docker) container?_
-
-1. Transparency. Making the containers within the Pod visible to the
- infrastructure enables the infrastructure to provide services to those
- containers, such as process management and resource monitoring. This
- facilitates a number of conveniences for users.
-1. Decoupling software dependencies. The individual containers may be
- versioned, rebuilt and redeployed independently. Kubernetes may even support
- live updates of individual containers someday.
-1. Ease of use. Users don't need to run their own process managers, worry about
- signal and exit-code propagation, etc.
-1. Efficiency. Because the infrastructure takes on more responsibility,
- containers can be lighter weight.
-
-_Why not support affinity-based co-scheduling of containers?_
-
-That approach would provide co-location, but would not provide most of the
-benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
-simplified management.
-
-## Durability of pods (or lack thereof)
-
-Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
-
-In general, users shouldn't need to create Pods directly. They should almost
-always use controllers even for singletons, for example,
-[Deployments](/docs/concepts/workloads/controllers/deployment/).
-Controllers provide self-healing with a cluster scope, as well as replication
-and rollout management.
-Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
-can also provide support to stateful Pods.
-
-The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
-
-Pod is exposed as a primitive in order to facilitate:
-
-* scheduler and controller pluggability
-* support for pod-level operations without the need to "proxy" them via controller APIs
-* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
-* decoupling of controllers and services — the endpoint controller just watches Pods
-* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
-* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
-
-## Termination of Pods
-
-Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
-
-An example flow:
-
-1. User sends command to delete Pod, with default grace period (30s)
-1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
-1. Pod shows up as "Terminating" when listed in client commands
-1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
- 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete.
- 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
-1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
-1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
-1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
-
-By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
-You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
-
-### Force deletion of pods
-
-Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-
-Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-
-## Privileged mode for pod containers
-
-Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
-
-{{< note >}}
-Your container runtime must support the concept of a privileged container for this setting to be relevant.
-{{< /note >}}
-
-## API Object
-
-Pod is a top-level resource in the Kubernetes REST API.
-The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
-describes the object in detail.
-When creating the manifest for a Pod object, make sure the name specified is a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
-
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index f77e34a3f9..9cbb7bdff8 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -1,7 +1,7 @@
---
reviewers:
- jessfraz
-title: Pod Preset
+title: Pod Presets
content_type: concept
weight: 50
---
@@ -32,20 +32,20 @@ specific service do not need to know all the details about that service.
In order to use Pod presets in your cluster you must ensure the following:
-1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
- example, this can be done by including `settings.k8s.io/v1alpha1=true` in
- the `--runtime-config` option for the API server. In minikube add this flag
- `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
- starting the cluster.
-1. You have enabled the admission controller `PodPreset`. One way to doing this
- is to include `PodPreset` in the `--enable-admission-plugins` option value specified
- for the API server. In minikube, add this flag
-
- ```shell
- --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
- ```
-
- while starting the cluster.
+1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
+ example, this can be done by including `settings.k8s.io/v1alpha1=true` in
+ the `--runtime-config` option for the API server. In minikube add this flag
+ `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
+ starting the cluster.
+1. You have enabled the admission controller named `PodPreset`. One way to doing this
+ is to include `PodPreset` in the `--enable-admission-plugins` option value specified
+ for the API server. For example, if you use Minikube, add this flag:
+
+ ```shell
+ --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+ ```
+
+ while starting your cluster.
## How it works
@@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following:
modified by a `PodPreset`. The annotation is of the form
`podpreset.admission.kubernetes.io/podpreset-: ""`.
-Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be
-applied to zero or more pods. When a `PodPreset` is applied to one or more
-Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
-`VolumeMounts`, Kubernetes modifies the container spec for all containers in
-the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
+Each Pod can be matched by zero or more PodPresets; and each PodPreset can be
+applied to zero or more Pods. When a PodPreset is applied to one or more
+Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and
+`volumeMounts`, Kubernetes modifies the container spec for all containers in
+the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec.
{{< note >}}
A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
-- The `.spec.containers` field.
-- The `initContainers` field (requires Kubernetes version 1.14.0 or later).
+- The `.spec.containers` field
+- The `.spec.initContainers` field
{{< /note >}}
-### Disable Pod Preset for a Specific Pod
+### Disable Pod Preset for a specific pod
There may be instances where you wish for a Pod to not be altered by any Pod
-Preset mutations. In these cases, you can add an annotation in the Pod Spec
+preset mutations. In these cases, you can add an annotation in the Pod's `.spec`
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
-
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
-
-
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index d8f57e5e82..cd1b03efd4 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -28,41 +28,62 @@ Kubernetes documentation welcomes improvements from all contributors, new and ex
## Getting started
-Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community.
+Anyone can open an issue about documentation, or contribute a change with a
+pull request (PR) to the
+[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website).
+You need to be comfortable with
+[git](https://git-scm.com/) and
+[GitHub](https://lab.github.com/)
+to work effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
-3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
+1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+ and the website's [static site generator](https://gohugo.io).
+1. Make sure you understand the basic processes for
+ [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
+ [reviewing changes](/docs/contribute/review/reviewing-prs/).
Some tasks require more trust and more access in the Kubernetes organization.
-See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
+See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
roles and permissions.
## Your first contribution
-- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
-- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points.
-- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
-- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
-- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
+- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
+ learn about the different ways you can contribute.
+- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
+ for issues that make good entry points.
+- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
+ to existing documentation and learn more about filing issues in GitHub.
+- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other
+ Kubernetes community members for accuracy and language.
+- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and
+ [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Learn about [page content types](/docs/contribute/style/page-content-types/)
+ and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
-- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository.
+- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo)
+ of the repository.
- Document [features in a release](/docs/contribute/new-content/new-features/).
-- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities).
+- Participate in [SIG Docs](/docs/contribute/participate/), and become a
+ [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/).
+
- Start or help with a [localization](/docs/contribute/localization/).
## Get involved with SIG Docs
-[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project.
+[SIG Docs](/docs/contribute/participate/) is the group of contributors who
+publish and maintain Kubernetes documentation and the website. Getting
+involved with SIG Docs is a great way for Kubernetes contributors (feature
+development or otherwise) to have a large impact on the Kubernetes project.
SIG Docs communicates with different methods:
-- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to
+- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 4c6a3f415a..52ae7b0efd 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -13,13 +13,12 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-
-
## Propose improvements
-SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
+SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members)
+can propose improvements.
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
@@ -42,8 +41,8 @@ documentation testing might involve working with sig-testing.
## Coordinate docs for a Kubernetes release
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
-docs for a Kubernetes release.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can coordinate docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
@@ -73,8 +72,8 @@ rotated among SIG Docs approvers.
## Serve as a New Contributor Ambassador
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
-New Contributor Ambassadors.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve as New Contributor Ambassadors.
New Contributor Ambassadors welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
@@ -92,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
## Sponsor a new contributor
-SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
-new contributors.
+SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers)
+can sponsor new contributors.
After a new contributor has successfully submitted 5 substantive pull requests
to one or more Kubernetes repositories, they are eligible to apply for
-[membership](/docs/contribute/participating#members) in the Kubernetes
-organization. The contributor's membership needs to be backed by two sponsors
-who are already reviewers.
+[membership](/docs/contribute/participate/roles-and-responsibilities/#members)
+in the Kubernetes organization. The contributor's membership needs to be
+backed by two sponsors who are already reviewers.
New docs contributors can request sponsors by asking in the #sig-docs channel
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
@@ -111,7 +110,8 @@ membership in the Kubernetes organization.
## Serve as a SIG Co-chair
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve a term as a co-chair of SIG Docs.
### Prerequisites
@@ -120,7 +120,12 @@ Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
-- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
+- Understand how other Kubernetes SIGs and repositories affect the SIG Docs
+ workflow, including:
+ [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+ [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
+ plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
+ [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
### Responsibilities
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index a1fed1642e..ea6065472e 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -15,21 +15,16 @@ like
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
This topic does not show how to generate the
-[kubectl](/docs/reference/generated/kubectl/kubectl/)
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
options reference page. For instructions on how to generate the kubectl options
reference page, see
-[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
+[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/).
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Setting up the local repositories
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index f68d81dfb4..f2ec01d8e8 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -194,16 +194,14 @@ The use of `make docker-serve` is deprecated. Please use `make container-serve`
In `` run `git add` and `git commit` to commit the change.
Submit your changes as a
-[pull request](/docs/contribute/start/) to the
+[pull request](/docs/contribute/new-content/open-a-pr/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-
## {{% heading "whatsnext" %}}
-
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
index a777fb77e5..c719920813 100644
--- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
+++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
@@ -18,4 +18,5 @@
- You need to know how to create a pull request to a GitHub repository.
This involves creating your own fork of the repository. For more
- information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
+ information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo).
+
diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md
index df5cdbb95f..0790f7925a 100644
--- a/content/en/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md
@@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Getting the docs repository
@@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps:
the sections in the `kubectl` command reference.
When the generated files are in your local clone of the ``
-repository, you can submit them in a [pull request](/docs/contribute/start/)
+repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/)
to ``.
## Configuration file format
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 0c698305b9..1ae4796522 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -183,7 +183,7 @@ Description | URLs
-----|-----
Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
-Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
+Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 98998d7f74..d511360e22 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -1,6 +1,5 @@
---
title: Opening a pull request
-slug: new-content
content_type: concept
weight: 10
card:
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index e9ef332430..b1f7e4f20a 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
+- In addition to the standard Hugo shortcodes, we use a number of
+ [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+ language has its own folder with a two-letter code determined by the
+ [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
+ example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md
index a99eaf464e..a5c0f2880a 100644
--- a/content/en/docs/contribute/participate/_index.md
+++ b/content/en/docs/contribute/participate/_index.md
@@ -20,18 +20,18 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a
pull request (PR), and anyone is welcome to file issues about content or comment
on pull requests in progress.
-You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
-[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater
-access and entail certain responsibilities for approving and committing changes.
-See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members),
+[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or
+[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers).
+These roles require greater access and entail certain responsibilities for
+approving and committing changes. See
+[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for more information on how membership works within the Kubernetes community.
The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
-
-
## SIG Docs chairperson
@@ -58,8 +58,9 @@ There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/
Each can be referenced with their `@name` in GitHub comments to communicate with
everyone in that group.
-Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals,
-the automation uses information from `OWNERS` files.
+Sometimes Prow and GitHub teams overlap without matching exactly. For
+assignment of issues, pull requests, and to support PR approvals, the
+automation uses information from `OWNERS` files.
### OWNERS files and front-matter
@@ -114,6 +115,6 @@ SIG Docs approvers. Here's how it works.
For more information about contributing to the Kubernetes documentation, see:
-- [Contributing new content](/docs/contribute/overview/)
+- [Contributing new content](/docs/contribute/new-content/overview/)
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
index 6538e813df..c2ab60a811 100644
--- a/content/en/docs/contribute/participate/pr-wranglers.md
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -36,16 +36,16 @@ The following queries are helpful when wrangling.
After working through these queries, the remaining list of PRs to review is usually small.
These queries exclude localization PRs. All queries are against the main branch except the last one.
-- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
+- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
-- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
+- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
-- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
+- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
Lists PRs that need an `/approve` comment to merge.
-- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
-- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
### When to close Pull Requests
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md
new file mode 100644
index 0000000000..8ebe7a1303
--- /dev/null
+++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md
@@ -0,0 +1,237 @@
+---
+title: Roles and responsibilities
+content_type: concept
+weight: 10
+---
+
+
+
+Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow,
+you can apply for different levels of membership in the community.
+These roles allow you to take on more responsibility within the community.
+Each role requires more time and commitment. The roles are:
+
+- Anyone: regular contributors to the Kubernetes documentation
+- Members: can assign and triage issues and provide non-binding review on pull requests
+- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
+- Approvers: can lead reviews on documentation and merge changes
+
+
+
+## Anyone
+
+Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
+
+Anyone can:
+
+- Open an issue in any [Kubernetes](https://github.com/kubernetes/)
+ repository, including
+ [`kubernetes/website`](https://github.com/kubernetes/website)
+- Give non-binding feedback on a pull request
+- Contribute to a localization
+- Suggest improvements on [Slack](https://slack.k8s.io/) or the
+ [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
+
+- Open a pull request to improve existing content, add new content, or write a blog post or case study
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+
+For more information, see [contributing new content](/docs/contribute/new-content/).
+
+## Members
+
+A member is someone who has submitted multiple pull requests to
+`kubernetes/website`. Members are a part of the
+[Kubernetes GitHub organization](https://github.com/kubernetes).
+
+Members can:
+
+- Do everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
+
+ {{< note >}}
+ Using `/lgtm` triggers automation. If you want to provide non-binding
+ approval, simply commenting "LGTM" works too!
+ {{< /note >}}
+
+- Use the `/hold` comment to block merging for a pull request
+- Use the `/assign` comment to assign a reviewer to a pull request
+- Provide non-binding review on pull requests
+- Use automation to triage and categorize issues
+- Document new features
+
+### Becoming a member
+
+After submitting at least 5 substantial pull requests and meeting the other
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
+
+1. Find two [reviewers](#reviewers) or [approvers](#approvers) to
+ [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your
+ membership.
+
+ Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
+ [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+ {{< note >}}
+ Don't send a direct email or Slack direct message to an individual
+ SIG Docs member. You must request sponsorship before submitting your application.
+ {{< /note >}}
+
+1. Open a GitHub issue in the
+ [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the
+ **Organization Membership Request** issue template.
+
+1. Let your sponsors know about the GitHub issue. You can either:
+ - Mention their GitHub username in an issue (`@`)
+ - Send them the issue link using Slack or email.
+
+ Sponsors will approve your request with a `+1` vote. Once your sponsors
+ approve the request, a Kubernetes GitHub admin adds you as a member.
+ Congratulations!
+
+ If your membership request is not accepted you will receive feedback.
+ After addressing the feedback, apply again.
+
+1. Accept the invitation to the Kubernetes GitHub organization in your email account.
+
+ {{< note >}}
+ GitHub sends the invitation to the default email address in your account.
+ {{< /note >}}
+
+## Reviewers
+
+Reviewers are responsible for reviewing open pull requests. Unlike member
+feedback, you must address reviewer feedback. Reviewers are members of the
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub team.
+
+Reviewers can:
+
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Review pull requests and provide binding feedback
+
+ {{< note >}}
+ To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
+ {{< /note >}}
+
+- Edit user-facing strings in code
+- Improve code comments
+
+You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
+
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
+review from a specific person by commenting: `/assign
+[@_github_handle]`.
+
+If the assigned reviewer has not commented on the PR, another reviewer can
+step in. You can also assign technical reviewers as needed.
+
+### Using `/lgtm`
+
+LGTM stands for "Looks good to me" and indicates that a pull request is
+technically accurate and ready to merge. All PRs need a `/lgtm` comment from a
+reviewer and a `/approve` comment from an approver to merge.
+
+A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
+
+### Becoming a reviewer
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
+you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
+separately for reviewer status in SIG Docs.
+
+To apply:
+
+1. Open a pull request that adds your GitHub user name to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
+ in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
+ {{< /note >}}
+
+1. Assign the PR to one or more SIG-Docs approvers (user names listed under
+ `sig-docs-{language}-owners`).
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## Approvers
+
+Approvers review and approve pull requests for merging. Approvers are members of the
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub teams.
+
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling
+
+If the PR already has a `/lgtm`, or if the approver also comments with
+`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a
+`/lgtm` on a change that doesn't need additional technical review.
+
+
+### Approving pull requests
+
+Approvers and SIG Docs leads are the only ones who can merge pull requests
+into the website repository. This comes with certain responsibilities.
+
+- Approvers can use the `/approve` command, which merges PRs into the repo.
+
+ {{< warning >}}
+ A careless merge can break the site, so be sure that when you merge something, you mean it.
+ {{< /warning >}}
+
+- Make sure that proposed changes meet the
+ [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
+
+ If you ever have a question, or you're not sure about something, feel free
+ to call for additional review.
+
+- Verify that Netlify tests pass before you `/approve` a PR.
+
+
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md
deleted file mode 100644
index f4cca67155..0000000000
--- a/content/en/docs/contribute/participate/roles-and-responsibilties.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Roles and responsibilities
-content_type: concept
-weight: 10
----
-
-
-
-Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
-These roles allow you to take on more responsibility within the community.
-Each role requires more time and commitment. The roles are:
-
-- Anyone: regular contributors to the Kubernetes documentation
-- Members: can assign and triage issues and provide non-binding review on pull requests
-- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
-- Approvers: can lead reviews on documentation and merge changes
-
-
-
-## Anyone
-
-Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
-
-Anyone can:
-
-- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
-- Give non-binding feedback on a pull request
-- Contribute to a localization
-- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-
-- Open a pull request to improve existing content, add new content, or write a blog post or case study
-- Create diagrams, graphics assets, and embeddable screencasts and videos
-
-For more information, see [contributing new content](/docs/contribute/new-content/).
-
-## Members
-
-A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
-
-Members can:
-
-- Do everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
-
- {{< note >}}
- Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
- {{< /note >}}
-- Use the `/hold` comment to block merging for a pull request
-- Use the `/assign` comment to assign a reviewer to a pull request
-- Provide non-binding review on pull requests
-- Use automation to triage and categorize issues
-- Document new features
-
-### Becoming a member
-
-After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
-
-1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
-
- Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member. You must request sponsorship before submitting your application.
- {{< /note >}}
-
-2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-
-3. Let your sponsors know about the GitHub issue. You can either:
- - Mention their GitHub username in an issue (`@`)
- - Send them the issue link using Slack or email.
-
- Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
-
- If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
-
-4. Accept the invitation to the Kubernetes GitHub organization in your email account.
-
- {{< note >}}
- GitHub sends the invitation to the default email address in your account.
- {{< /note >}}
-
-## Reviewers
-
-Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
-
-Reviewers can:
-
-- Do everything listed under [Anyone](#anyone) and [Members](#members)
-- Review pull requests and provide binding feedback
-
- {{< note >}}
- To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
- {{< /note >}}
-
-- Edit user-facing strings in code
-- Improve code comments
-
-You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
-
-### Assigning reviewers to pull requests
-
-Automation assigns reviewers to all pull requests. You can request a
-review from a specific person by commenting: `/assign
-[@_github_handle]`.
-
-If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
-
-### Using `/lgtm`
-
-LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
-
-A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
-
-### Becoming a reviewer
-
-When you meet the
-[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs.
-
-To apply:
-
-1. Open a pull request that adds your GitHub user name to a section of the
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
-in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
- {{< /note >}}
-
-2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## Approvers
-
-Approvers review and approve pull requests for merging. Approvers are members of the
-[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
-
-Approvers can do the following:
-
-- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
-- Publish contributor content by approving and merging pull requests using the `/approve` comment
-- Propose improvements to the style guide
-- Propose improvements to docs tests
-- Propose improvements to the Kubernetes website or other tooling
-
-If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review.
-
-
-### Approving pull requests
-
-Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
-
-- Approvers can use the `/approve` command, which merges PRs into the repo.
-
- {{< warning >}}
- A careless merge can break the site, so be sure that when you merge something, you mean it.
- {{< /warning >}}
-
-- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
-
- If you ever have a question, or you're not sure about something, feel free to call for additional review.
-
-- Verify that Netlify tests pass before you `/approve` a PR.
-
-
-
-- Visit the Netlify page preview for a PR to make sure things look good before approving.
-
-- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/).
-for more details.
-
-### Becoming an approver
-
-When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
-
-To apply:
-
-1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
- {{< /note >}}
-
-2. Assign the PR to one or more current SIG Docs approvers.
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## {{% heading "whatsnext" %}}
-
-- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
\ No newline at end of file
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 0cddbcba6a..82a05bdb86 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -8,7 +8,9 @@ weight: 20
-SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
+SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
+[Approvers](/docs/contribute/participate/#approvers) do a few extra things
+when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -19,9 +21,6 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-
-
-
## Reviewing a PR
@@ -202,9 +201,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
-[Kubernetes slack](http://slack.k8s.io/). You can also search
+[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index 3c271aa44f..ff6ef9d709 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
-[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-
-
+ [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Understand the different
+ [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/)
+ in the Kubernetes documentation community.
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index 569ca8d72c..0de4a381a3 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -10,9 +10,9 @@ weight: 10
This page contains guidelines for Kubernetes documentation.
If you have questions about what's allowed, join the #sig-docs channel in
-[Kubernetes Slack](http://slack.k8s.io/) and ask!
+[Kubernetes Slack](https://slack.k8s.io/) and ask!
-You can register for Kubernetes Slack at http://slack.k8s.io/.
+You can register for Kubernetes Slack at https://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
@@ -67,7 +67,7 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes
### More information
-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
+If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index e4a6d703ad..ab949be7fc 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -232,7 +232,7 @@ Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
-{{< tab name="JSON File" include="podtemplate" />}}
+{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
@@ -242,6 +242,6 @@ Renders to:
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/contribute/style/page-content-types/).
-* Learn about [creating a pull request](/docs/contribute/new-content/new-content/).
+* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
index 2a3325d397..5d3b519bc0 100644
--- a/content/en/docs/contribute/style/page-content-types.md
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines:
interested in reading next.
An example of a published tutorial topic is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
### Reference
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 55aa30d66c..44653708ec 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -22,8 +22,11 @@ discussion.
{{< note >}}
-Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
-and representing feature state.
+Kubernetes documentation uses
+[Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
+with some adjustments along with a few
+[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support
+glossary entries, tabs, and representing feature state.
{{< /note >}}
## Language
@@ -584,12 +587,8 @@ The Federation feature provides ... | The new Federation feature provides ...
{{< /table >}}
-
-
## {{% heading "whatsnext" %}}
-
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [using page templates](/docs/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 3e4f999c08..7cac1aa6b7 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs.
## {{% heading "prerequisites" %}}
Create a fork of the Kubernetes documentation repository as described in
-[Open a PR](/docs/new-content/open-a-pr/).
+[Open a PR](/docs/contribute/new-content/open-a-pr/).
@@ -160,7 +160,7 @@ submitted to ensure all examples pass the tests.
{{< /note >}}
For an example of a topic that uses this technique, see
-[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
+[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/).
## Adding images to a topic
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index c0747f3d56..7e1f8ced66 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -677,9 +677,6 @@ for more information.
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
for more information.
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index d196be938d..398f06b671 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 1227f750eb..a9db3b00eb 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -997,7 +997,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
### Matching requests: matchPolicy
API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 20b1224e59..2be833826c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation.
### User-facing roles
@@ -649,12 +653,15 @@ metadata:
```
-
### Core component roles
-
### Other component roles
-
### Roles for built-in controllers {#controller-roles}
diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md
index f14393072c..b551dead19 100755
--- a/content/en/docs/reference/glossary/pod.md
+++ b/content/en/docs/reference/glossary/pod.md
@@ -2,7 +2,7 @@
title: Pod
id: pod
date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /docs/concepts/workloads/pods/
short_description: >
A Pod represents a set of running containers in your cluster.
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 25b7d46af9..c0adee3bdb 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API.
To eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
The version is set at the API level rather than at the resource or field level to:
@@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve
to pick up the `--runtime-config` changes.
{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
new file mode 100644
index 0000000000..a7be3b267f
--- /dev/null
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -0,0 +1,103 @@
+---
+title: Kubernetes API health endpoints
+reviewers:
+- logicalhan
+content_type: concept
+weight: 50
+---
+
+
+The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
+This page describes these API endpoints and explains how you can use them.
+
+
+
+## API endpoints for health
+
+The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
+The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
+The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
+For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
+Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
+A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
+
+The following examples will show how you can interact with the health API endpoints.
+
+For all endpoints you can use the `verbose` parameter to print out the checks and their status.
+This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+
+ ```shell
+ curl -k https://localhost:6443/livez?verbose
+ ```
+
+or from a remote host with authentication:
+
+ ```shell
+ kubectl get --raw='/readyz?verbose'
+ ```
+
+The output will look like this:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ healthz check passed
+
+The Kubernetes API server also supports to exclude specific checks.
+The query parameters can also be combined like in this example:
+
+ ```shell
+ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+ ```
+
+The output show that the `etcd` check is excluded:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd excluded: ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ [+]shutdown ok
+ healthz check passed
+
+## Individual health checks
+
+{{< feature-state state="alpha" >}}
+
+Each individual health check exposes an http endpoint and could can be checked individually.
+The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server.
+The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
+These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
+
+ ```shell
+ curl -k https://localhost:6443/livez/etcd
+ ```
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index c8692c8872..2b8f7b487f 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
@@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
### Addon Resources
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
For example:
@@ -94,28 +94,26 @@ For example:
memory: 200Mi
```
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
- * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
- * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
- * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+ * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+ * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+ * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
- * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+ * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
- * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
- * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+ * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+ * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
### Allowing minor node failure at startup
@@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh
with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
reason for the failure, those additional nodes may join later or the cluster may remain at a size of
`NUM_NODES - ALLOWED_NOTREADY_NODES`.
+
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index ab61c839a9..7c2622641b 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -78,7 +78,7 @@ federation support).
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
### Volume limitations
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
index a794141f2d..009be9adc8 100644
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ b/content/en/docs/setup/learning-environment/minikube.md
@@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo
The `minikube start` command can be used to start your cluster.
This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
+This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster.
{{< note >}}
If you are behind a web proxy, you need to pass this information to the `minikube start` command:
@@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
## Community
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
index 1f7d1fd81f..c440f14b31 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
@@ -9,12 +9,10 @@ content_type: concept
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-
-
## Prerequisites
@@ -112,10 +110,7 @@ e9af8293... role=node
## Support Level
-
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md
index 7cbeccf7cb..8394c28faf 100644
--- a/content/en/docs/setup/production-environment/tools/kops.md
+++ b/content/en/docs/setup/production-environment/tools/kops.md
@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
but not under `example.com`).
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
@@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
## {{% heading "whatsnext" %}}
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index aa9245ea65..82184f7784 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -8,7 +8,7 @@ weight: 30
-The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
-(CNI) based Pod network add-on so that your Pods can communicate with each other.
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
- networks: you are likely to see problems if there is any overlap.
+ networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
@@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
- control).
+ control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
- supports IPv6.
+ supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
{{< /caution >}}
@@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers.
{{< /note >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
-See the list of available
-[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
@@ -297,79 +297,6 @@ kubectl apply -f
```
You can install only one Pod network per cluster.
-Below you can find installation instructions for some popular Pod network plugins:
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
-
-Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-
-To deploy Cilium you just need to run:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
-```
-
-Once all Cilium Pods are marked as `READY`, you start using your cluster.
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-The output is similar to this:
-```
-NAME READY STATUS RESTARTS AGE
-cilium-drxkl 1/1 Running 0 18m
-```
-
-Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
-
-For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
-
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
-offering feature-rich & high-performance cloud-native networking and services.
-
-It implements k8s services and network policies in the user space (on VPP).
-
-Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
-
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
-
-For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-
-For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/).
-
-Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
-Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
-if they don't know their PodIP.
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-{{% /tab %}}
-
-{{< /tabs >}}
-
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
@@ -578,9 +505,9 @@ options.
* See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
for details about upgrading your cluster using `kubeadm`.
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
-of Pod network add-ons.
+ of Pod network add-ons.
* See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
explore other add-ons, including tools for logging, monitoring, network policy, visualization &
control of your Kubernetes cluster.
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 5584309406..e91e9f7a60 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool
If you encounter issues with setting up the HA cluster, please provide us with feedback
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
-See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
{{< caution >}}
This page does not address running your cluster on a cloud provider. In a cloud
@@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
-
-
## {{% heading "prerequisites" %}}
@@ -51,8 +49,6 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-
-
## First steps for both methods
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 334e2266f2..d860a88bdd 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -13,14 +13,12 @@ weight: 100
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/)
configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-
-
#### Caveats
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index a4d6d54cc2..696778f974 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
+- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`,
+ or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-
-
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 64ad3f4b1a..02d99d926a 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -8,7 +8,7 @@ weight: 30
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
* composable attributes
@@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* openSUSE Leap 15
* continuous integration tests
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-
-
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
@@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment:
### (2/5) Compose an inventory file
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
@@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* {{< glossary_tooltip term_id="cri-o" >}}
* Certificate generation methods
-Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
### (4/5) Deploy a Cluster
@@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
index cbfccd7a56..be75623158 100644
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ b/content/en/docs/setup/production-environment/turnkey/aws.md
@@ -48,7 +48,7 @@ export PATH=/platforms/darwin/amd64:$PATH
export PATH=/platforms/linux/amd64:$PATH
```
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
+An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
@@ -63,7 +63,8 @@ For more complete applications, please look in the [examples directory](https://
## Scaling the cluster
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
+Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
+[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
## Tearing down the cluster
@@ -80,13 +81,8 @@ cluster/kube-down.sh
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
-AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
-AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
+AWS | CoreOS | CoreOS | flannel | - | | Community
+AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
index 60c4e690d9..3ea666eb7c 100644
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ b/content/en/docs/setup/production-environment/turnkey/gce.md
@@ -72,7 +72,7 @@ cluster/kube-up.sh
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
The next few steps will show you:
@@ -85,7 +85,7 @@ The next few steps will show you:
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
manager. It lets you inspect your cluster resources, create, delete, and update
components, and much more. You will use it to look at your new cluster and bring
up example apps.
@@ -98,7 +98,7 @@ gcloud components install kubectl
{{< note >}}
The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
document to see how you can set up the latest `kubectl` on your workstation.
{{< /note >}}
@@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
kubectl get --all-namespaces services
```
-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
```shell
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
@@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3
...
```
-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
You can do this via the
```shell
@@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
### Run some examples
-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
@@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index b0c5f1596d..812d86faf7 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications
## Windows containers in Kubernetes
-To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
+To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
@@ -65,7 +65,7 @@ From an API and kubectl perspective, Windows containers behave in much the same
Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
-* [Pods](/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/docs/concepts/workloads/pods/)
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index 6a115f72cc..310127f838 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
## Supported versions
Kubernetes versions are expressed as **x.y.z**,
-where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
+where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 9288ec3064..a0c68ff682 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Create `example-ingress.yaml` from the following file:
- apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
+ apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-ingress
@@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via
Output:
```shell
- ingress.extensions/example-ingress configured
+ ingress.networking/example-ingress configured
```
## Test Your Ingress
diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
index fe90981432..1194288386 100644
--- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment:
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has two
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has two
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
+
1. Display information about the Deployment:
```shell
kubectl get deployments hello-world
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 729c7bde4f..be7cbf2673 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -19,15 +19,15 @@ PersistentVolume.
## Why change reclaim policy of a PersistentVolume
-`PersistentVolumes` can have various reclaim policies, including "Retain",
-"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
+PersistentVolumes can have various reclaim policies, including "Retain",
+"Recycle", and "Delete". For dynamically provisioned PersistentVolumes,
the default reclaim policy is "Delete". This means that a dynamically provisioned
volume is automatically deleted when a user deletes the corresponding
-`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume
+PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
contains precious data. In that case, it is more appropriate to use the "Retain"
-policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
-the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
-`Released` phase, where all of its data can be manually recovered.
+policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
+the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
+Released phase, where all of its data can be manually recovered.
## Changing the reclaim policy of a PersistentVolume
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 6fd887bd8f..f333b215a2 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
The output is:
- deployment.extensions/dns-autoscaler scaled
+ deployment.apps/dns-autoscaler scaled
Verify that the replica count is zero:
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e82c53f3a6..c3498fce61 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### Joining a Windows worker node
{{< note >}}
You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
{{< /note >}}
{{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
index b4b7afd6de..1d1461ade7 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
This example assumes the following:
1. You have an [existing Kubernetes cluster](/docs/setup/).
-2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
## Understand the default namespace
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index 1b47b14188..00dec41774 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
## {{% heading "prerequisites" %}}
* Have an [existing Kubernetes cluster](/docs/setup/).
-* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index e18b2ed87d..ed1b9657c8 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites:
You can use `kubectl drain` to safely evict all of your pods from a
node before you perform maintenance on the node (e.g. kernel upgrade,
hardware maintenance, etc.). Safe evictions allow the pod's containers
-to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
and will respect the `PodDisruptionBudgets` you have specified.
{{< note >}}
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index f5116e7691..00b9251be8 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes.
Kubernetes sends the preStop event immediately before the Container is terminated.
Kubernetes' management of the Container blocks until the preStop handler completes,
unless the Pod's grace period expires. For more details, see
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
{{< note >}}
Kubernetes only sends the preStop event when a Pod is *terminated*.
diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md
index 5189fdb882..cf31d822d6 100644
--- a/content/en/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/static-pod.md
@@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Unlike Pods that are managed by the control plane (for example, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}});
-instead, the kubelet watches each static Pod (and restarts it if it crashes).
+instead, the kubelet watches each static Pod (and restarts it if it fails).
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index f64a55bd29..aad8aac2ee 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -133,6 +133,40 @@ log audit backend using the following `kube-apiserver` flags:
- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example,
+`
+--audit-policy-file=/etc/kubernetes/audit-policy.yaml
+--audit-log-path=/var/log/audit.log
+`
+then mount the volumes:
+
+
+```
+volumeMounts:
+ - mountPath: /etc/kubernetes/audit-policy.yaml
+ name: audit
+ readOnly: true
+ - mountPath: /var/log/audit.log
+ name: audit-log
+ readOnly: false
+```
+finally the hostPath:
+
+```
+- name: audit
+ hostPath:
+ path: /etc/kubernetes/audit-policy.yaml
+ type: File
+
+- name: audit-log
+ hostPath:
+ path: /var/log/audit.log
+ type: FileOrCreate
+
+```
+
+
+
### Webhook backend
Webhook backend sends audit events to a remote API, which is assumed to be the
@@ -206,7 +240,7 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
If you're extending the Kubernetes API with the [aggregation
layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/),
-y ou can also set up audit logging for the aggregated apiserver. To do this,
+you can also set up audit logging for the aggregated apiserver. To do this,
pass the configuration options in the same format as described above to the
aggregated apiserver and set up the log ingesting pipeline to pick up audit
logs. Different apiservers can have different audit configurations and
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index a5c37541c3..edd23c35e7 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -118,7 +118,7 @@ You can view this resource with:
kubectl get endpoints ${SERVICE_NAME}
```
-Make sure that the endpoints match up with the number of containers that you expect to be a member of your service.
+Make sure that the endpoints match up with the number of pods that you expect to be members of your service.
For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different
IP addresses in the Service's endpoints.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 9793b472e0..8fb5bffd37 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
- [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and with
+ Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md
deleted file mode 100644
index 634b9d33c1..0000000000
--- a/content/en/docs/tasks/debug-application-cluster/falco.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: Auditing with Falco
----
-
-
-### Use Falco to collect audit events
-
-[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
-This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
-
-
-
-#### Install Falco
-
-Install Falco by using one of the following methods:
-
-- [Standalone Falco](https://falco.org/docs/installation)
-- [Kubernetes DaemonSet](https://falco.org/docs/installation)
-- [Falco Helm Chart](https://github.com/falcosecurity/charts/tree/master/falco)
-
-Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
-
-```yaml
-webserver:
- enabled: true
- listen_port: 8765
- k8s_audit_endpoint: /k8s_audit
- ssl_enabled: false
- ssl_certificate: /etc/falco/falco.pem
-```
-
-This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
-
-#### Configure Kubernetes Audit
-
-1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
- for the [kube-apiserver](/docs/reference/generated/kube-apiserver/) webhook audit backend.
-
- cat < /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
-
-1. Start `kube-apiserver` with the following options:
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
-
-#### Audit Rules
-
-Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml](https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml).
-If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
-
-There are three classes of rules.
-
-The first class of rules looks for suspicious or exceptional activities, such as:
-
-- Any activity by an unauthorized or anonymous user.
-- Creating a pod with an unknown or disallowed image.
-- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
-- Creating a NodePort service.
-- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
-- Attaching to or executing a command on a running pod.
-- Creating a namespace external to a set of allowed namespaces.
-- Creating a pod or service account in the kube-system or kube-public namespaces.
-- Trying to modify or delete a system ClusterRole.
-- Creating a ClusterRoleBinding to the cluster-admin role.
-- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
-- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
-
-A second class of rules tracks resources being created or destroyed, including:
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
-
-The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
-
-For further details, see [Kubernetes Audit Events](https://falco.org/docs/event-sources/kubernetes-audit) in the Falco documentation.
-
-
diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 4afbee21c8..b14777111e 100644
--- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -129,45 +129,8 @@ If RBAC is enabled on your cluster, you must update the `system:kube-scheduler`
```
kubectl edit clusterrole system:kube-scheduler
```
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- annotations:
- rbac.authorization.kubernetes.io/autoupdate: "true"
- labels:
- kubernetes.io/bootstrapping: rbac-defaults
- name: system:kube-scheduler
-rules:
-- apiGroups:
- - coordination.k8s.io
- resources:
- - leases
- verbs:
- - create
-- apiGroups:
- - coordination.k8s.io
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - leases
- verbs:
- - get
- - update
-- apiGroups:
- - ""
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - endpoints
- verbs:
- - delete
- - get
- - patch
- - update
-```
+
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
## Specify schedulers for pods
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index 7a4a94fab4..57e54e6797 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp
### Persistent Volumes
-Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
{{< note >}}
Use caution when deleting a PVC, as it may lead to data loss.
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 48a61a260d..e706c6179a 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods
```
-For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver.
+For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 7f3b046b68..6806ba0dc0 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -47,7 +47,7 @@ The Dockerfile has the following content:
```
FROM php:5-apache
-ADD index.php /var/www/html/index.php
+COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index cabf9a3c7b..7f43d34be7 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -2,5 +2,40 @@
title: "Install Tools"
description: Set up Kubernetes tools on your computer.
weight: 10
+no_list: true
---
+## kubectl
+
+The Kubernetes command-line tool, `kubectl`, allows you to run commands against
+Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
+cluster resources, and view logs.
+
+See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
+download and install `kubectl` and set it up for accessing your cluster.
+
+You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
+Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
+or for daily development work.
+
+You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
+guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
+is on getting the tool installed.
+
+Once you have Minikube working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+
+## kind
+
+Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local compute. Unlike Minikuke, kind only works with a single container runtime:
+it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
+and configured.
+
+[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
+need to do to get up and running with kind.
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 25b5cab9b5..22b960751f 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -28,7 +28,7 @@ You must use a kubectl version that is within one minor version difference of yo
1. Download the latest release with the command:
```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 9ba2de1abf..f0aa44369e 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re
## Create a Deployment
-A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
+A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 6d7e15a7c4..fb782458de 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 8a7d60dd87..c610b6e9f4 100644
--- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
{{< /blocks/section >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..b607f0b82d
--- /dev/null
+++ b/content/es/docs/concepts/configuration/configmap.md
@@ -0,0 +1,253 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+
+
+{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}}
+
+{{< caution >}}
+ConfigMap no proporciona encriptación.
+Si los datos que quieres almacenar son confidenciales, utiliza un
+{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap,
+o utiliza otras herramientas externas para mantener los datos seguros.
+{{< /caution >}}
+
+
+
+
+## Motivo
+
+Utiliza un ConfigMap para crear una configuración separada del código de la aplicación.
+
+Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en
+tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real).
+Escribes el código para configurar una variable llamada `DATABASE_HOST`.
+En tu equipo configuras la variable con el valor `localhost`.
+En el cloud, la configuras con referencia a un kubernetes
+{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente
+de la base de datos en tu cluster.
+
+Esto permite tener una imagen corriendo en un cloud y
+tener el mismo código localmente para checkearlo si es necesario.
+
+## Objeto ConfigMap
+
+Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API
+que permite almacenar la configuración de otros objetos utilizados. Aunque muchos
+objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para
+almacenar items, identificados por una clave, y sus valores.
+
+El nombre del ConfigMap debe ser un
+[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
+
+## ConfigMaps y Pods
+
+Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es)
+de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en
+el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+
+Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple,
+y otras claves donde el valor tiene un formato de un fragmento de configuración.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # property-like keys; each key maps to a simple value
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+ #
+ # file-like keys
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+Hay cuatro maneras diferentes de usar un ConfigMap para configurar
+un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Argumento en la linea de comandos como entrypoint de un contenedor
+1. Variable de enorno de un contenedor
+1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación
+1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap
+
+Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar
+los datos que se van a usar.
+Para los primeros tres mecanismos, el
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información
+del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+
+Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos.
+Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede
+suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar
+cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta
+técnica también permite acceder al ConfigMap en diferentes namespaces.
+
+En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: game.example/demo-game
+ env:
+ # Define the environment variable
+ - name: PLAYER_INITIAL_LIVES # Notice that the case is different here
+ # from the key name in the ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # The ConfigMap this value comes from.
+ key: player_initial_lives # The key to fetch.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # You set volumes at the Pod level, then mount them into containers inside that Pod
+ - name: config
+ configMap:
+ # Provide the name of the ConfigMap you want to mount.
+ name: game-demo
+ # An array of keys from the ConfigMap to create as files
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+
+Un ConfigMap no diferencia entre las propiedades de una linea individual y
+un fichero con múltiples lineas y valores.
+Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores.
+
+Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor
+`demo` como `/config` creando dos ficheros,
+`/config/game.properties` y `/config/user-interface.properties`,
+aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición
+del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`.
+Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en
+un fichero con el mismo nombre que la clave, y tienes 4 ficheros.
+
+## Usando ConfigMaps
+
+Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras
+partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo,
+los ConfigMaps pueden contener información para que otros elementos del sistema utilicen
+para su configuración.
+
+{{< note >}}
+La manera más común de usar los Configmaps es para configurar
+los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+También se pueden usar por separado.
+
+Por ejemplo,
+quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}}
+u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que
+ajustan su comportamiento en base a un ConfigMap.
+{{< /note >}}
+
+### Usando ConfigMaps como ficheros en un Pod
+
+Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap.
+1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap.
+1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap.
+1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`.
+
+En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`.
+
+Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio
+bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap.
+
+#### ConfigMaps montados son actualizados automáticamente
+
+Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también.
+El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización.
+Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap.
+El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo
+todas las consultas directamente a la API.
+Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento
+que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}}
++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de
+caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar
+{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión
+(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus
+datos con las siguientes ventajas:
+
+- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones
+- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}},
+cerrando las vistas para el ConfigMap marcado como inmutable.
+
+Para usar esta característica, habilita el `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura
+el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio
+ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap.
+Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable
+recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+{{< /note >}}
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Leer sobre [Secrets](/docs/concepts/configuration/secret/).
+* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar
+ el código de la configuración.
diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..577e24dc1f
--- /dev/null
+++ b/content/es/docs/reference/glossary/configmap.md
@@ -0,0 +1,18 @@
+---
+title: Configmap
+id: configmap
+date: 2020-07-11
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+ Almacena información no sensible.
+
+aka:
+tags:
+- workload
+---
+Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}.
+
+Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables.
+
+
+
diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md
index 8d60357aea..2a88388374 100644
--- a/content/fr/docs/tasks/tools/install-kubectl.md
+++ b/content/fr/docs/tasks/tools/install-kubectl.md
@@ -121,7 +121,7 @@ kubectl version --client
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
-2. Rendrez le binaire kubectl exécutable.
+2. Rendez le binaire kubectl exécutable.
```
chmod +x ./kubectl
diff --git a/content/id/_index.html b/content/id/_index.html
index 47d7f71ced..e95d661b76 100644
--- a/content/id/_index.html
+++ b/content/id/_index.html
@@ -4,7 +4,6 @@ abstract: "Otomatisasi Kontainer deployment, scaling, dan management"
cid: home
---
-{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
@@ -60,4 +59,4 @@ Kubernetes sebagai open source memberikan kamu kebebasan untuk menggunaka
{{< blocks/kubernetes-features >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md
index ebc205d84a..33f4ada445 100644
--- a/content/id/docs/concepts/_index.md
+++ b/content/id/docs/concepts/_index.md
@@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail.
Objek mendasar Kubernetes termasuk:
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
+* [Pod](/id/docs/concepts/workloads/pods/pod-overview/)
+* [Service](/id/docs/concepts/services-networking/service/)
+* [Volume](/id/docs/concepts/storage/volumes/)
+* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/)
Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler.
Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
+* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/)
## *Control Plane* Kubernetes
@@ -95,7 +95,7 @@ dengan *node* secara langsung.
#### Metadata objek
-* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/)
+* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/)
diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md
index a0ff6b9256..6cf90cf9e6 100644
--- a/content/id/docs/concepts/architecture/controller.md
+++ b/content/id/docs/concepts/architecture/controller.md
@@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan.
Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari
Kubernetes.
-[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
+[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau
lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat
keadaan sekarang mendekati keadaan yang diinginkan.
@@ -174,6 +174,6 @@ khusus itu lakukan.
* Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane)
* Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects)
-* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
-* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
+* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/)
+* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md
index 8913c9df65..ab13cf122a 100644
--- a/content/id/docs/concepts/architecture/nodes.md
+++ b/content/id/docs/concepts/architecture/nodes.md
@@ -8,8 +8,8 @@ weight: 10
Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya.
-Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
-Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
+Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
+Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node).
@@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk
Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali.
Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan.
-Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
+Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual.
Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.
-Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
+Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod.
Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel.
@@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node.
## Manajemen
-Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
+Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat.
Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak.
Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
@@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m
Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints.
Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`.
-Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
+Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition.
Ini merupakan fitur alpha untuk versi 1.8.
@@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak
Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node.
Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node.
-Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
+Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md
index b404465d8f..ca50347492 100644
--- a/content/id/docs/concepts/cluster-administration/addons.md
+++ b/content/id/docs/concepts/cluster-administration/addons.md
@@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
* [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan.
-* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal.
## _Service Discovery_
diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md
index a605a78547..ee1f91cbeb 100644
--- a/content/id/docs/concepts/cluster-administration/certificates.md
+++ b/content/id/docs/concepts/cluster-administration/certificates.md
@@ -245,6 +245,6 @@ done.
Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan
sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan
-[di sini](/docs/tasks/tls/managing-tls-in-a-cluster).
+[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster).
diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md
index 45820e3660..9a32af1eb8 100644
--- a/content/id/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md
@@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan
Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node.
### *Load Balancer*
-Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
+Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
```yaml
apiVersion: v1
diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
index b485b5e142..b2bd349908 100644
--- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent
Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan:
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
- - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
+ - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/).
- Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**?
- Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster.
- - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai.
+ - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai.
- Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**?
- Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster.
@@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
* Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/).
-* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
+* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
## Mengamankan Klaster
-* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
+* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
-* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
+* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
* [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*.
@@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
## Layanan Tambahan Klaster
-* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
+* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
-* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
+* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md
index 7690a75a82..d59da126ad 100644
--- a/content/id/docs/concepts/cluster-administration/federation.md
+++ b/content/id/docs/concepts/cluster-administration/federation.md
@@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
-* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
+* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/)
[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
index 53203777f2..75f3b97189 100644
--- a/content/id/docs/concepts/cluster-administration/logging.md
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna
{{< /note >}}
Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
-yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
+yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md
index 81c0ba4d08..d67da9c13e 100644
--- a/content/id/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md
@@ -6,7 +6,7 @@ weight: 40
-Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/).
+Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/).
@@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`).
-Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
+Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
## Memperbarui anotasi
@@ -309,7 +309,7 @@ metadata:
...
```
-Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
+Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
## Memperbesar dan memperkecil aplikasi kamu
@@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image
kubectl edit deployment/my-nginx
```
-Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/).
+Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/).
@@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang
- [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/)
+- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/)
diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md
index 038465bcb8..6bcd78d7ef 100644
--- a/content/id/docs/concepts/cluster-administration/networking.md
+++ b/content/id/docs/concepts/cluster-administration/networking.md
@@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja.
Ada 4 masalah yang berbeda untuk diatasi:
1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh
- [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
+ [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
-3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
-4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
+3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
+4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
@@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus
### Romana
-[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
+[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
### Weave Net dari Weaveworks
diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md
index 5595414aa9..f3567233e0 100644
--- a/content/id/docs/concepts/cluster-administration/proxies.md
+++ b/content/id/docs/concepts/cluster-administration/proxies.md
@@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai proxy yang ada di dalam Kubernetes.
Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes:
-1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- dijalankan pada desktop pengguna atau di dalam sebuah Pod
- melakukan proxy dari alamat localhost ke apiserver Kubernetes
@@ -23,7 +23,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- mencari lokasi apiserver
- menambahkan header autentikasi
-1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- merupakan sebuah bastion yang ada di dalam apiserver
- menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau
@@ -33,7 +33,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- dapat digunakan untuk menghubungi Node, Pod, atau Service
- melakukan load balancing saat digunakan untuk menjangkau sebuah Service
-1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- dijalankan pada setiap Node
- melakukan proxy untuk UDP, TCP dan SCTP
diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md
index 8af1abba28..ee9e8bf2f4 100644
--- a/content/id/docs/concepts/configuration/assign-pod-node.md
+++ b/content/id/docs/concepts/configuration/assign-pod-node.md
@@ -7,7 +7,7 @@ weight: 30
-Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
+Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/)
@@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node:
Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
-Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
+Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
@@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
-Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
+Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
## nodeName
diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
index 3450bab459..600a4cc6cd 100644
--- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
@@ -10,7 +10,7 @@ feature:
-Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu
+Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu
dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan
oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya,
scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih
@@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_)
CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup
_sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan,
-dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/).
-Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah
+dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/).
+Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah
objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server.
## Request dan Limit Sumber daya dari Pod dan Container
@@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab
memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat
[Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
-Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk
+Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk
membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace,
kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya.
@@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node.
##### Sumber daya Device Plugin yang dikelola
Lihat [Device
-Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
+Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node.
##### Sumber daya lainnya
diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index 929c895821..caba991a8d 100644
--- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig,
bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster]
-(/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
@@ -103,7 +103,7 @@ kubeconfig:
abaikan mereka.
Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada
- [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+ [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`,
tanpa melakukan penggabungan.
@@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak.
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md
index 76d68658ec..67fb2061fe 100644
--- a/content/id/docs/concepts/configuration/overview.md
+++ b/content/id/docs/concepts/configuration/overview.md
@@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
-- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
+- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
- Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
+ Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
## Services
-- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
+- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
```shell
FOO_SERVICE_HOST=
@@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
-- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS.
+- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
- Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+ Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
- Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
+ Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
-- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless-
+- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
## Menggunakan label
-- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
+- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
-Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
+Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol.
@@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan
## Container Images
-Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
+Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
- `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal.
@@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`.
-- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md
index e59301bb96..13db4e32f8 100644
--- a/content/id/docs/concepts/configuration/pod-overhead.md
+++ b/content/id/docs/concepts/configuration/pod-overhead.md
@@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka
Pada Kubernetes, Overhead Pod ditentukan pada
[saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam
-[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod.
+[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod.
Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container
saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran
@@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u
## {{% heading "whatsnext" %}}
-* [RuntimeClass](/docs/concepts/containers/runtime-class/)
+* [RuntimeClass](/id/docs/concepts/containers/runtime-class/)
* [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md
index a0c6035482..7350470fa3 100644
--- a/content/id/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md
@@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan
1.11 | beta | ya
1.14 | stable | ya
-{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
+{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
{{< /warning >}}
@@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya
#### Penghentian secara sopan dari korban-korban pemindahan Pod
-Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
+Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
#### PodDisruptionBudget didukung, tapi tidak dijamin!
-Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
+Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
#### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah
diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md
index a6ca8dca88..40875648ff 100644
--- a/content/id/docs/concepts/configuration/secret.md
+++ b/content/id/docs/concepts/configuration/secret.md
@@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no
atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan
hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan.
-Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/)
+Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/)
untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_.
### Membuat Objek Secret Kamu Sendiri
@@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni
{{< note >}}
Sebuah container menggunakan Secret sebagai
-[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_
+[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_
yang di-_mount_ tidak akan menerima perubahan Secret.
{{< /note >}}
@@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P
**Memberikan spesifikasi manual dari sebuah imagePullSecret**
-Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan
@@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull
yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan
serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari
serviceAccount yang digunakan.
-Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
+Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
untuk informasi lebih detail soal proses yang dijalankan.
### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat
@@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_.
Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada
secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi
-akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources)
+akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources)
yang dibutuhkan aplikasi.
Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain
diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md
index 9a30b48f5b..723bbd1c9c 100644
--- a/content/id/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/id/docs/concepts/configuration/taint-and-toleration.md
@@ -6,7 +6,7 @@ weight: 40
-Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
+Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
@@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
-bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
@@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten
dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan.
{{< note >}}
-Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
+Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
pada skenario dimana master menjadi terpisah dari _node_ lainnya.
@@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi.
Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds
_admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
-_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
+_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
`NoExecute` untuk _taint_ tanpa `tolerationSeconds`:
* `node.kubernetes.io/unreachable`
diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md
index affb371001..6c0ba354e8 100644
--- a/content/id/docs/concepts/containers/container-environment.md
+++ b/content/id/docs/concepts/containers/container-environment.md
@@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada
*Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer:
-* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/).
+* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/).
* Informasi tentang Kontainer tersebut.
* Informasi tentang objek-objek lain di dalam klaster.
@@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
* Dapatkan pengalaman praktis soal
[memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
index a7b5164864..d45a5ad23e 100644
--- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
@@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono
untuk menghapus kontainer tersebut.
Tidak ada parameter yang diberikan pada *handler*.
-Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods).
### Implementasi *handler* untuk *hook*
@@ -113,7 +113,7 @@ Events:
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/).
+* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/).
* Pelajari bagaimana caranya
[melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md
index 7a5fa28154..8fa81801ff 100644
--- a/content/id/docs/concepts/containers/images.md
+++ b/content/id/docs/concepts/containers/images.md
@@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut:
- buang `imagePullPolicy` dan juga _tag_ untuk _image_.
- aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_.
-Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
+Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
## Membuat Image Multi-arsitektur dengan Manifest
@@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo
* `DOCKER_EMAIL`: `${some-email-address}`
Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat
-[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Menggunakan IBM Cloud Container Registry
IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu
@@ -291,7 +291,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER
Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas,
kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret.
-[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
+[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat,
perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan
hanya bekerja menggunakan satu registri privat.
@@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr
Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam
sumber daya [serviceAccount](/docs/user-guide/service-accounts).
-Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
+Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial
akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine.
diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md
index d31c760ee0..715230d14d 100644
--- a/content/id/docs/concepts/containers/overview.md
+++ b/content/id/docs/concepts/containers/overview.md
@@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda.
## Image-Image Kontainer
-[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak
+[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak
yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan
sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari
aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting.
diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md
index 31bd8a25ec..73252a03e4 100644
--- a/content/id/docs/concepts/containers/runtime-class.md
+++ b/content/id/docs/concepts/containers/runtime-class.md
@@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki.
Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya
konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari
yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass
-melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)).
+melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)).
{{< /note >}}
Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass.
@@ -91,7 +91,7 @@ spec:
Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut
untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat
-menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
+menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait.
Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan.
diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index d8be642856..3a3ece65b0 100644
--- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k
## _Custom Resource_
-Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
+Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular.
@@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men
Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya.
-Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
+Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini.
Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API.
@@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API
| Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan |
| Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. |
| Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. |
-| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
+| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
| Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. |
| Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. |
@@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku:
* Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui.
{{< note >}}
-Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
+Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
{{< /note >}}
Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku:
@@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar
Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu:
- CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun.
-- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
+- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan.
-_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
+_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD.
@@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll
Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition).
-[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
+[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
## Memilih sebuah metode untuk menambahkan _Custom Resource_
@@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan
## {{% heading "whatsnext" %}}
-* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 3bde2909ca..62f7c8d41d 100644
--- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim:
* Nama Unix socket-nya.
* Versi API Plugin Perangkat yang dipakai.
* `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti
- [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+ [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
sebagai `vendor-domain/tipe-sumber-daya`.
(Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.)
diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
index b7b07b46ff..9d80881724 100644
--- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
-*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
+*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
## Perluasan
@@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber
### Menggabungkan API Baru dengan Otomasi
-Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
+Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
### Mengubah Sumber Daya Bawaan
@@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo
* [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/)
* [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/)
* Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/)
-* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/)
+* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/)
diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md
index 269f7312a1..315ae35e3d 100644
--- a/content/id/docs/concepts/extend-kubernetes/operator.md
+++ b/content/id/docs/concepts/extend-kubernetes/operator.md
@@ -7,7 +7,7 @@ weight: 30
Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan
-[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip
Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane).
@@ -126,7 +126,7 @@ menggunakan bahasa / _runtime_ yang dapat bertindak sebagai
## {{% heading "whatsnext" %}}
-* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/)
untuk memenuhi use case kamu
* Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya:
diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
index efea4eda97..cd63a89355 100644
--- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
@@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API
merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut.
Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan.
-Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index 63e7b4b3af..aa2ee52152 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya. -[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini @@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya. ### Web UI (Dasbor) -[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. +[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun aplikasi yang ada pada klaster itu sendiri. @@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan. ### Cluster-level Logging -[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada +[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian. diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md index 9599feaf24..46066769d4 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut: -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan dalam dokumen ini: @@ -862,8 +862,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md index e77cc9ca63..23489efb59 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md index 7df68f579d..94f1082e35 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -108,8 +108,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md index 8a822f255d..aaa238add5 100644 --- a/content/id/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md @@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku ## {{% heading "whatsnext" %}} -Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/). +Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/). diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md index 7cd81495cd..e46916ee3d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,14 +3,14 @@ title: Selektor Field weight: 60 --- -Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan +Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*: * `metadata.name=my-service` * `metadata.namespace!=default` * `status.phase=Pending` -Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai +Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai `Running`: ```shell @@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default ## Selektor berantai -Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai +Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai (*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan `Running` dan *field* `spec.restartPolicy` sama dengan `Always`: diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 57eef5e9c6..aa702827b9 100644 --- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan. Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu -harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). +harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/). Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan. @@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/). +* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/). diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md index 5527c15b72..0d6528c41d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/names.md +++ b/content/id/docs/concepts/overview/working-with-objects/names.md @@ -8,7 +8,7 @@ weight: 20 Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID. -Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/). +Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/). Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID. diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md index 5eb358a17a..89ffb8ea14 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster *Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*. -*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). +*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)). Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*. @@ -74,7 +74,7 @@ kubectl config view | grep namespace: ## Namespace dan DNS -Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
+Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
## Tidak semua objek di dalam Namespace
diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md
index 2dbbd53144..991ebb44aa 100644
--- a/content/id/docs/concepts/policy/pod-security-policy.md
+++ b/content/id/docs/concepts/policy/pod-security-policy.md
@@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk
## Mengizinkan Kebijakan
-Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
+Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
-Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
+Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
### Melalui RBAC
-[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
+[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut:
@@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya
name: system:authenticated
```
-Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples).
Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh).
### Mengatasi Masalah
-- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
+- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles).
## Urutan Kebijakan
@@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode.
### Volume dan _file system_
-**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
+**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
**Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut:
diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md
index 47bfa996bb..c001ef4a40 100644
--- a/content/id/docs/concepts/policy/resource-quotas.md
+++ b/content/id/docs/concepts/policy/resource-quotas.md
@@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung:
### Resource Quota untuk sumber daya yang diperluas
Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk
-[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
+[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan
keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk
@@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi
## Resource Quota untuk penyimpanan
-Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat
+Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat
diminta pada sebuah Namespace.
Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_
@@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut.
| Nama Sumber Daya | Deskripsi |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. |
-| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
| `.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. |
-| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut:
@@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung:
| Nama Sumber Daya | Deskripsi |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. |
-| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
+| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
| `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. |
| `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. |
| `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. |
@@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k
{{< feature-state for_k8s_version="1.12" state="beta" >}}
-Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
+Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan
kolom `scopeSelector` pada spesifikasi kuota tersebut.
diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md
index f4cd477608..6f7efab3d9 100644
--- a/content/id/docs/concepts/scheduling/kube-scheduler.md
+++ b/content/id/docs/concepts/scheduling/kube-scheduler.md
@@ -94,10 +94,10 @@ penilaian oleh penjadwal:
## {{% heading "whatsnext" %}}
-* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/)
-* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_
* Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/)
-* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/)
+* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/)
diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
index 0a20d9050a..3689ecf7cb 100644
--- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
+++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -8,7 +8,7 @@ weight: 70
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
-[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
+[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
@@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim
persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
-akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md
index caff040bc5..bc271e0645 100644
--- a/content/id/docs/concepts/security/overview.md
+++ b/content/id/docs/concepts/security/overview.md
@@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi
## {{% heading "whatsnext" %}}
-* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/)
+* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/)
* Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/)
* Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/)
-* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/)
-* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/)
+* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/)
diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md
index 4bbd0bbf56..806fff3a46 100644
--- a/content/id/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/id/docs/concepts/services-networking/connect-applications-service.md
@@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
-Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
+Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
## Membuat Service
@@ -107,7 +107,7 @@ NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
```
-Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
+Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
## Mengakses Service
@@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum
* *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*)
* Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut
-* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
+* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya:
@@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
## {{% heading "whatsnext" %}}
-Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
+Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md
index 52ec19a420..efdba8d7a1 100644
--- a/content/id/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/id/docs/concepts/services-networking/dns-pod-service.md
@@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada.
### SRV _record_
SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless
-Services](/docs/concepts/services-networking/service/#headless-services).
+Services](/id/docs/concepts/services-networking/service/#headless-services).
Untuk setiap port bernama, SRV _record_ akan memiliki format
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan
diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md
index 224e7b4bbd..1782f4273e 100644
--- a/content/id/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/id/docs/concepts/services-networking/endpoint-slices.md
@@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki
referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan
_endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik.
Nama dari sebuah objek EndpointSlice haruslah berupa
-[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
+[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes
yang bernama `example`.
@@ -180,6 +180,6 @@ bersangkutan.
* [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md
index 9491f5dc1c..645f2dbf8d 100644
--- a/content/id/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/id/docs/concepts/services-networking/ingress-controllers.md
@@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang
## {{% heading "whatsnext" %}}
-* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut.
+* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut.
* [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube)
diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md
index 617581b421..1cc56c5960 100644
--- a/content/id/docs/concepts/services-networking/ingress.md
+++ b/content/id/docs/concepts/services-networking/ingress.md
@@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak
* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes.
* Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
-* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
-* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
+* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/).
+* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
## Apakah *Ingress* itu?
@@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa
```
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
-Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
+Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan
-*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau
-[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
+*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau
+[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer).
## Prasyarat
@@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se
Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta.
{{< note >}}
-Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
+Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
{{< /note >}}
GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut
@@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE.
Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus
[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis
-[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
+[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
### Sebelum kamu memulai
@@ -89,10 +89,10 @@ spec:
```
Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`.
- Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/).
+ Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/).
Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
+ [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan.
[Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress
@@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum
*loadbalancer* akan mengarahkan trafik pada *service* yang sesuai.
* Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di
- [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
+ [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
*host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait.
*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah
@@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
### *Backend Default*
Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang
-biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
+biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut
akan diarahkan pada *backend default*.
@@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga
pada kolom `address`.
{{< note >}}
-Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/)
-bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
+Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/)
+bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
{{< /note >}}
### Virtual Host berbasis Nama
@@ -291,7 +291,7 @@ spec:
### TLS
-Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret)
+Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret)
yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya
memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS.
Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda,
@@ -448,8 +448,8 @@ Ingress yang ingin diubah.
## Mekanisme *failing* pada beberapa zona *availability*
Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*.
-Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers)
-untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/)
+Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers)
+untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/)
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster.
## Pengembangan selanjutnya
@@ -463,8 +463,8 @@ soal perubahan berbagai kontroler.
Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan:
-* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
-* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer)
+* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport)
* [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md
index 25f42ddb98..fe510b846d 100644
--- a/content/id/docs/concepts/services-networking/network-policies.md
+++ b/content/id/docs/concepts/services-networking/network-policies.md
@@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy.
**_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy`
membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai
bagaimana bekerja dengan _file_ `config`, dapat dilihat di
-[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/),
serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/).
**spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu.
diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md
index ef15d1ab3d..05abffa323 100644
--- a/content/id/docs/concepts/services-networking/service-topology.md
+++ b/content/id/docs/concepts/services-networking/service-topology.md
@@ -186,5 +186,5 @@ spec:
* Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology)
-* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md
index 97626bf9ce..00bf4e6241 100644
--- a/content/id/docs/concepts/services-networking/service.md
+++ b/content/id/docs/concepts/services-networking/service.md
@@ -12,9 +12,9 @@ weight: 10
-[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
+[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut
-tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara
+tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara
khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*).
Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP
yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
@@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada.
Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi
set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_.
-Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors)
(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa
sebuah _selector_).
@@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja:
* Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_,
kamu ingin menggunakan basis datamu sendiri.
* Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada
- [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
+ [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
* Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih
berada di luar klaster Kubernetes.
@@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini.
### DNS
-Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional
+Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional
(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah
terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis
@@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_.
Server DNS Kubernetes adalah satu-satunya cara untuk mengakses
_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di
-[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/).
+[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/).
## `Service` _headless_
@@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun.
Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan
_DaemonSet_ atau melakukan spesifikasi
-[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
+[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
agar `Pod` tidak di-_assign_ ke _node_ yang sama.
-NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer).
+NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer).
Agar trafik klien berhasil mencapai _instances_ dibelakang ELB,
_security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut:
@@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS.
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)),
_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_
di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks
[protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md
index ac206dfacd..4b9fa6f35c 100644
--- a/content/id/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/id/docs/concepts/storage/dynamic-provisioning.md
@@ -8,7 +8,7 @@ weight: 40
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus
-memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
+memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/)
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
ketika diminta oleh pengguna.
@@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
memilih berbagai macam pilihan penyimpanan.
-Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/).
+Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/).
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
@@ -123,6 +123,6 @@ tidak bisa terbuat.
Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
-[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
+[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md
index f75941b86a..51163d36a9 100644
--- a/content/id/docs/concepts/storage/persistent-volumes.md
+++ b/content/id/docs/concepts/storage/persistent-volumes.md
@@ -11,7 +11,7 @@ weight: 20
-Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/).
+Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/).
@@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl
kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya
`StorageClass`.
-Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
## Siklus hidup dari sebuah volume dan klaim
@@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi:
Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut
`storageClassName` menjadi nama
-[StorageClass](/docs/concepts/storage/storage-classes/).
+[StorageClass](/id/docs/concepts/storage/storage-classes/).
Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta
kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat
dengan PVC yang tidak meminta kelas tertentu.
@@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.
### Afinitas Node
{{< note >}}
-Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local).
+Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local).
{{< /note >}}
Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_.
@@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas
### _Selector_
-Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
+Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
* `matchLabels` - volume harus memiliki label dengan nilai ini
* `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist.
@@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak
### Kelas
Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari
-[StorageClass](/docs/concepts/storage/storage-classes/)
+[StorageClass](/id/docs/concepts/storage/storage-classes/)
menggunakan atribut `storageClassName`.
Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat
terikat dengan PVC.
@@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/).
+Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/).
Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan
gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_.
diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md
index 9e0a5b1664..2897399e80 100644
--- a/content/id/docs/concepts/storage/storage-classes.md
+++ b/content/id/docs/concepts/storage/storage-classes.md
@@ -8,8 +8,8 @@ weight: 30
Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes.
Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap
-[volumes](/docs/concepts/storage/volumes/) dan
-[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu.
+[volumes](/id/docs/concepts/storage/volumes/) dan
+[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu.
@@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.
Administrator dapat memberikan spesifikasi StorageClass _default_ bagi
PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_:
-kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
untuk penjelasan lebih lanjut.
```yaml
@@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid.
### Mode Volume _Binding_
_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan
-_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning)
+_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning)
harus dilakukan.
Secara _default_, ketika mode `Immediate` yang mengindikasikan
@@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan
PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_
sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan
oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada,
-[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container),
-[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector),
+[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container),
+[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector),
[afinitas dan
-anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
-serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration).
+anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration).
Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_
dinamis:
@@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat:
* [Lokal](#lokal)
{{< feature-state state="beta" for_k8s_version="1.14" >}}
-[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung
+[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung
dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat,
meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi
untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung
@@ -634,8 +634,8 @@ parameters:
di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan.
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster
-menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan
-[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles),
+menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan
+[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles),
menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole
`system:controller:persistent-volume-binder`.
diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md
index 4a5f5d8c8c..481e74c976 100644
--- a/content/id/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md
@@ -7,7 +7,7 @@ weight: 30
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan.
+Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan.
diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md
index 0414a9d7de..fff7de9baa 100644
--- a/content/id/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,8 +7,8 @@ weight: 30
Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan,
-sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/)
-dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu.
+sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/)
+dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu.
diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md
index 39ab3d31aa..5ddfc2aaa6 100644
--- a/content/id/docs/concepts/storage/volume-snapshots.md
+++ b/content/id/docs/concepts/storage/volume-snapshots.md
@@ -7,7 +7,7 @@ weight: 20
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
+Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
@@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing
#### Dinamis
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot.
-Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi.
### Ikatan (_Binding_)
@@ -93,7 +93,7 @@ spec:
### _Class_
Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut
-`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
+`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/).
VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang
"meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat
terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_.
@@ -117,7 +117,7 @@ spec:
### _Class_
Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
menggunakan atribut `snapshotClassName`.
Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama
dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
@@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan
menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim.
-Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
+Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md
index 679de8c865..8d593f1eba 100644
--- a/content/id/docs/concepts/storage/volumes.md
+++ b/content/id/docs/concepts/storage/volumes.md
@@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk
### configMap {#configmap}
-Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
+Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod.
Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini:
@@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang
Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`.
{{< caution >}}
-Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
+Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
{{< /caution >}}
{{< note >}}
@@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r
#### Menyediakan sebuah Regional PD PersistentVolume Secara Manual
-Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce).
+Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce).
Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya:
```shell
@@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc
Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`.
-Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
+Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner).
@@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github
### persistentVolumeClaim {#persistentvolumeclaim}
-Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
+Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
-Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
+Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
### projected {#projected}
@@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github
### scaleIO {#scaleio}
-ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
+ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)).
{{< caution >}}
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
@@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya
Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`.
-Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
+Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
#### Volume CSI Sementara
diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
index 29fde331ea..ca5df2d86d 100644
--- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
@@ -6,7 +6,7 @@ weight: 80
-Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
+Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala
pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron).
@@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik
Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi.
{{< /note >}}
-Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs).
+Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs).
diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md
index baa79aa3f2..0b1c0e71e9 100644
--- a/content/id/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/id/docs/concepts/workloads/controllers/daemonset.md
@@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_
`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/),
-[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/).
+[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/).
DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib
Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus
menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)).
-Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`.
DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer
keluar/berhenti atau terjadi _crash_.
@@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m
Objek `.spec.selector` memiliki dua _field_:
-* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/).
* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih
dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan
hubungan antara _key_ dan _value_.
@@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_.
Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan
membuat Pod pada Node yang cocok dengan [selektor
-Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
-maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/).
+Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
+maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/).
Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan
membuat Pod pada semua Node.
@@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut:
* Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat
dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini
membingungkan untuk pengguna.
- * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
+ * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/)
ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan,
_controller_ DaemonSet akan membuat keputusan penjadwalan tanpa
memperhitungkan prioritas Pod dan _preemption_.
@@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet.
### _Taint_ dan _Toleration_
Meskipun Pod Daemon menghormati
-[taint dan toleration](/docs/concepts/configuration/taint-and-toleration),
+[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration),
_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai
dengan fitur yang bersangkutan.
@@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon
- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain,
contohnya _stats database_. Pod ini tidak memiliki klien.
- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi.
-- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
+- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS.
- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada
Node random. (Tidak ada cara mengakses spesifik Node)
@@ -223,7 +223,7 @@ _bootstrapping_ klaster.
### Deployment
-DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka
+DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka
sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web,
peladen penyimpanan)
diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
index 4aca03535f..5f4720646b 100644
--- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community
_Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`.
-_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
+_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`.
Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job
haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor))
dan sebuah mekanisme _restart_ yang sesuai.
-Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
+Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
### Selektor Pod
@@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak
akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian,
program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika
tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan
-[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
+[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja,
ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau
@@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan.
Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan
objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job
yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti
-[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
+[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan.
### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan
@@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif
Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan
(baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan
menerapkan mekanisme TTL yang disediakan oleh
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan
_field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut.
@@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di
Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`.
Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai dijalankan.
## Pola Job
@@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati
Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job
mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_).
-Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
+Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`.
(Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.)
@@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y
## CronJob {#cron-jobs}
-Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
+Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix.
diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md
index c0c3a83d51..57b1124208 100644
--- a/content/id/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/id/docs/concepts/workloads/controllers/replicaset.md
@@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
+_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
```shell
matchLabels:
tier: frontend
@@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_
### Menghapus ReplicaSet dan Pod-nya
-Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
+Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d.
Sebagai contoh:
@@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
```
Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru.
-Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
+Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
### Mengisolasi Pod dari ReplicaSet
@@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10
### Deployment (direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri.
Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.
@@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
### ReplicationController
-ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
+ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
index f828ff9c64..48ec718a6d 100644
--- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -13,7 +13,7 @@ weight: 20
{{< note >}}
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
{{< /note >}}
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
@@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
-Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
+Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/).
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
-`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
+`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
-Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
+Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
@@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
+_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
@@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern
### ReplicaSet
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
+[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
### Deployment (Direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
### Pod sederhana
@@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
## Informasi lanjutan
diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md
index 9d12de91dd..aa99acd6e6 100644
--- a/content/id/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/id/docs/concepts/workloads/controllers/statefulset.md
@@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada
Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau
mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan
-replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
-[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
+replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau
+[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
## Keterbatasan
@@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads
pada Kubernetes rilis sebelum versi 1.5.
* Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator.
* Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait.
-* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
+* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan
[Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default,
@@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet.
* Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan.
* StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik.
-* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
+* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
```yaml
apiVersion: v1
@@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul
serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah
`$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod
dengan nama `web-0,web-1,web-2`.
-Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain klaster.
@@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi
_field_ `serviceName` pada StatefulSet.
Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab
-untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.
Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service,
@@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
{{< note >}}
Domain klaster akan diatur menjadi `cluster.local` kecuali
-[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/).
+[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Penyimpanan Stabil
-Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
+Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap
VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume
dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_
diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
index f2c232faf2..0e1b36ccc5 100644
--- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -10,7 +10,7 @@ weight: 65
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
+[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/),
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
@@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
-[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
dilakukan secara berantai, dimana sumber daya lain yang
@@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai
## {{% heading "whatsnext" %}}
-[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md
index 1adde6c949..7a09eed3a5 100644
--- a/content/id/docs/concepts/workloads/pods/disruptions.md
+++ b/content/id/docs/concepts/workloads/pods/disruptions.md
@@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod
PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB.
-Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).))
diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
index 45154caf25..e952bdd19b 100644
--- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan
menggunakan `kubectl exec` saja.
Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan
-[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/)
+[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/)
sehingga kamu dapat melihat proses pada kontainer lain.
### Contoh
diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md
index 91807fdaf6..9cd208fbc8 100644
--- a/content/id/docs/concepts/workloads/pods/init-containers.md
+++ b/content/id/docs/concepts/workloads/pods/init-containers.md
@@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp
## Memahami Init Container
-Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
+Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
Init Container sama saja seperti Container biasa, kecuali:
@@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container:
* Mengklon sebuah _git repository_ ke dalam sebuah _volume_.
* Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.
-Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
+Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
### Menggunakan Init Container
diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
index 8dac6706a7..fdb3e7b71c 100644
--- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions]
* `PodScheduled`: Pod telah dijadwalkan masuk ke node;
* `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;
- * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
+ * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
* `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain.
* `ContainersReady`: Semua kontainer di dalam Pod telah siap.
@@ -191,7 +191,7 @@ status:
...
```
-Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
+Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan
salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/).
@@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu:
sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang
bernilai OnFailure atau Never.
-- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau
- [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
+- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/),
+ [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau
+ [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy`
yang bernilai Always.
-- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
+- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
@@ -346,7 +346,7 @@ spec:
* Dapatkan pengalaman langsung mengenai
[pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
-* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md
index 0e9593e0d1..f427358999 100644
--- a/content/id/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/id/docs/concepts/workloads/pods/pod-overview.md
@@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod*
#### Penyimpanan
-*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
+*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
## Bekerja dengan Pod
@@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika
Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi:
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*.
## Templat Pod
Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
+[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan.
@@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem
## {{% heading "whatsnext" %}}
* Pelajari lebih lanjut tentang perilaku *Pod*:
- * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
+ * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods)
+ * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md
index 3838ec56b5..e25a3a9104 100644
--- a/content/id/docs/concepts/workloads/pods/pod.md
+++ b/content/id/docs/concepts/workloads/pods/pod.md
@@ -39,7 +39,7 @@ dan bisa saling berkomunikasi melalui `localhost`. Komunikasi tersebut mengunaka
standar _inter-process communications_ (IPC) seperti SystemV semaphores
atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP
yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa
-[pengaturan khusus](/docs/concepts/policy/pod-security-policy/). Kontainer ini
+[pengaturan khusus](/id/docs/concepts/policy/pod-security-policy/). Kontainer ini
biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod.
Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama,
@@ -51,14 +51,14 @@ gabungan dari kontainer Docker yang berbagi _namespace_ dan ruang penyimpanan _f
Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal
(tidak bertahan lama). Seperti yang didiskusikan dalam
-[siklus hidup Pod](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
+[siklus hidup Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan
ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan
(bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}}
mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah
suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang
ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa
dengan nama yang sama, tapi dengan ID unik yang baru
-(baca [_replication controller_](/docs/concepts/workloads/controllers/replicationcontroller/)
+(baca [_replication controller_](/id/docs/concepts/workloads/controllers/replicationcontroller/)
untuk info lebih lanjut)
Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan,
@@ -96,7 +96,7 @@ dan Pod lain dalam jaringan yang sama.
Kontainer dalam suatu Pod melihat _hostname_ sistem sebagai sesuatu yang sama
dengan konfigurasi `name` pada Pod. Informasi lebih lanjut terdapat dibagian
-[jaringan](/docs/concepts/cluster-administration/networking/).
+[jaringan](/id/docs/concepts/cluster-administration/networking/).
Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod,
Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan
@@ -153,10 +153,10 @@ kasus mesin sedang dalam pemeliharaan.
Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka
seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya,
-[_Deployment_](/docs/concepts/workloads/controllers/deployment/). Pengontrol
+[_Deployment_](/id/docs/concepts/workloads/controllers/deployment/). Pengontrol
menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan
pengelolaan replikasi dan penluncuran.
-Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md)
+Pengontrol seperti [_StatefulSet_](/id/docs/concepts/workloads/controllers/statefulset.md)
bisa memberikan dukungan terhadap Pod yang _stateful_.
Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang
@@ -202,7 +202,7 @@ bersama dengan masa tenggang.
1. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai
"Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod
1. Jika salah satu kontainer pada Pod memiliki
- [preStop _hook_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
+ [preStop _hook_](/id/docs/concepts/containers/container-lifecycle-hooks/#hook-details),
maka akan dipanggil di dalam kontainer. Jika `preStop` _hook_ masih berjalan
setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang
yang sedikit, 2 detik.
@@ -223,7 +223,7 @@ Secara _default_, semua penghapusan akan berjalan normal selama 30 detik. Perint
`kubectl delete` mendukung opsi `--grace-period=` yang akan
memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan
pengguna. Nilai `0` akan membuat Pod
-[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
+[dihapus paksa](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods).
Kamu harus memberikan opsi tambahan `--force` bersamaan dengan `--grace-period=0`
untuk melakukan penghapusan paksa.
@@ -243,7 +243,7 @@ dokumentasi untuk [penghentian Pod dari StatefulSet](/docs/tasks/run-application
## Hak istimewa untuk kontainer pada Pod
Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _privileged_), dengan menggunakan tanda
-`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/)
+`privileged` pada [konteks keamanan](/id/docs/tasks/configure-pod-container/security-context/)
pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan
kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam
kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer.
diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md
index 2fc1b8598b..9b899c4687 100644
--- a/content/id/docs/concepts/workloads/pods/podpreset.md
+++ b/content/id/docs/concepts/workloads/pods/podpreset.md
@@ -57,6 +57,6 @@ Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus mema
## {{% heading "whatsnext" %}}
- * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
+ * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/id/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md)
diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md
index 8dd4c02c3a..49aa20ed6e 100644
--- a/content/id/docs/reference/access-authn-authz/rbac.md
+++ b/content/id/docs/reference/access-authn-authz/rbac.md
@@ -24,7 +24,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
## Objek API {#api-overview}
API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole,
-RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
+RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
{{< caution >}}
Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan
@@ -100,7 +100,7 @@ rules:
verbs: ["get", "watch", "list"]
```
-Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
### RoleBinding dan ClusterRoleBinding
@@ -116,7 +116,7 @@ Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu
ClusterRoleBinding.
Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan
-[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
+[nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid.
#### Contoh RoleBinding
@@ -456,7 +456,7 @@ Di Kubernetes, modul otentikasi menyediakan informasi grup.
Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu,
selain awalan `system:` yang sudah direservasi.
-[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
+[ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
{{< note >}}
- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_.
@@ -1077,7 +1077,7 @@ In order from most secure to least secure, the approaches are:
--namespace=my-namespace
```
- Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+ Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the
"default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin
permissions to the "default" service account in the `kube-system` namespace.
diff --git a/content/id/docs/reference/kubectl/cheatsheet.md b/content/id/docs/reference/kubectl/cheatsheet.md
index 9afe999064..671ac6b77a 100644
--- a/content/id/docs/reference/kubectl/cheatsheet.md
+++ b/content/id/docs/reference/kubectl/cheatsheet.md
@@ -319,8 +319,8 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### Berbagai Tipe Sumber Daya
-Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/docs/concepts/overview/kubernetes-api/#api-groups),
-apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups),
+apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/id/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
diff --git a/content/id/docs/setup/production-environment/tools/_index.md b/content/id/docs/setup/production-environment/tools/_index.md
new file mode 100644
index 0000000000..fc98544230
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/_index.md
@@ -0,0 +1,4 @@
+---
+title: Menginstal Kubernetes dengan perkakas penyebaran
+weight: 30
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/_index.md b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
new file mode 100644
index 0000000000..f88a749c9b
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Menyiapkan klaster dengan kubeadm"
+weight: 10
+---
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index e0db168ccd..8a345296a3 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -66,7 +66,7 @@ Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _a
### Menginstal kubeadm pada hos
-Lihat ["Menginstal kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+Lihat ["Menginstal kubeadm"](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
{{< note >}}
Jika kamu sudah menginstal kubeadm sebelumnya, jalankan `apt-get update &&
@@ -94,7 +94,7 @@ yang spesifik pada penyedia tertentu. Lihat [Menginstal _add-on_ jaringan Pod](#
3. (Opsional) Sejak versi 1.14, `kubeadm` mencoba untuk mendeteksi _runtime_ kontainer pada Linux
dengan menggunakan daftar _domain socket path_ yang umum diketahui. Untuk menggunakan _runtime_ kontainer yang berbeda atau
jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen `--cri-socket`
-pada `kubeadm init`. Lihat [Menginstal _runtime_](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+pada `kubeadm init`. Lihat [Menginstal _runtime_](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
4. (Opsional) Kecuali ditentukan sebelumnya, `kubeadm` akan menggunakan antarmuka jaringan yang diasosiasikan
dengan _default gateway_ untuk mengatur alamat _advertise_ untuk API Server pada Node _control-plane_ ini.
Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen `--apiserver-advertise-address=`
@@ -262,7 +262,7 @@ DNS klaster (CoreDNS) tidak akan menyala sebelum jaringan dipasangkan.**
`--pod-network-cidr`, atau sebagai penggantinya pada YAML _plugin_ jaringan kamu).
- Secara bawaan, `kubeadm` mengatur klastermu untuk menggunakan dan melaksanakan penggunaan
- [RBAC](/docs/reference/access-authn-authz/rbac/) (_role based access control_).
+ [RBAC](/id/docs/reference/access-authn-authz/rbac/) (_role based access control_).
Pastikan _plugin_ jaringan Pod mendukung RBAC, dan begitu juga seluruh manifes
yang kamu gunakan untuk men-_deploy_-nya.
@@ -571,14 +571,14 @@ opsinya.
untuk detail mengenai pembaruan klaster menggunakan `kubeadm`.
* Pelajari penggunaan `kubeadm` lebih lanjut pada [dokumentasi referensi kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm)
* Pelajari lebih lanjut mengenai [konsep-konsep](/docs/concepts/) Kubernetes dan [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Lihat halaman [Cluster Networking](/docs/concepts/cluster-administration/networking/) untuk daftar
+* Lihat halaman [Cluster Networking](/id/docs/concepts/cluster-administration/networking/) untuk daftar
_add-on_ jaringan Pod yang lebih banyak.
-* Lihat [daftar _add-on_](/docs/concepts/cluster-administration/addons/) untuk
+* Lihat [daftar _add-on_](/id/docs/concepts/cluster-administration/addons/) untuk
mengeksplor _add-on_ lainnya, termasuk perkakas untuk _logging_, _monitoring_, _network policy_, visualisasi &
pengendalian klaster Kubernetes.
* Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari
aplikasi-aplikasi yang berjalan pada Pod.
- Lihat [Arsitektur Logging](/docs/concepts/cluster-administration/logging/) untuk
+ Lihat [Arsitektur Logging](/id/docs/concepts/cluster-administration/logging/) untuk
gambaran umum tentang hal-hal yang terlibat.
### Umpan balik
@@ -602,7 +602,7 @@ Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v{{< skew latestVers
Sumber daya ini menyediakan informasi lebih lanjut mengenai _version skew_ yang didukung antara kubelet dan _control plane_, serta komponen Kubernetes lainnya:
* [Kebijakan versi and version-skew Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Panduan instalasi](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
+* [Panduan instalasi](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm
## Keterbatasan
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
new file mode 100644
index 0000000000..afe6d1e6b8
--- /dev/null
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -0,0 +1,364 @@
+---
+title: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm
+content_type: task
+weight: 60
+---
+
+
+
+Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm:
+
+- Dengan Node _control plane_ yang bertumpuk (_stacked_). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node _control plane_ diletakkan pada tempat yang sama (_co-located_).
+- Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node _control plane_ dan anggota etcd berada pada tempat yang berbeda.
+
+Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan _environment_-mu. [Topik perbandingan berikut](/id/docs/setup/production-environment/tools/kubeadm/ha-topology/) menguraikan kelebihan dan kekurangan dari masing-masing pendekatan.
+
+Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik
+pada [pelacak isu](https://github.com/kubernetes/kubeadm/issues/new) kubeadm.
+
+Lihat juga [dokumentasi pembaruan](/id/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+
+{{< caution >}}
+Laman ini tidak menunjukkan cara untuk menjalankan klastermu pada penyedia layanan cloud. Pada _environment_ cloud, kedua pendekatan yang didokumentasikan di sini tidak akan bekerja untuk objek Service dengan tipe LoadBalancer maupun PersistentVolume dinamis.
+{{< /caution >}}
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut:
+
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk
+ Node _control plane_
+- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk Node _worker_
+- Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi)
+- Hak akses sudo pada seluruh mesin
+- Akses SSH dari satu perangkat ke seluruh Node pada sistem
+- Perkakas `kubeadm` dan `kubelet` diinstal pada seluruh mesin. Perkakas `kubectl` bersifat opsional.
+
+Untuk klaster etcd eksternal saja, kamu juga membutuhkan:
+
+- Tiga mesin tambahan untuk anggota-anggota etcd
+
+
+
+
+
+## Langkah pertama untuk kedua metode
+
+### Membuat _load balancer_ untuk kube-apiserver
+
+{{< note >}}
+Akan ada banyak konfigurasi untuk _load balancer_. Contoh berikut ini hanyalah salah satu
+opsi. Kebutuhan klastermu mungkin membutuhkan konfigurasi berbeda.
+{{< /note >}}
+
+1. Buat sebuah _load balancer_ kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS.
+
+ - Pada _environment_ cloud kamu harus meletakkan Node _control plane_ di belakang _load balancer_ yang meneruskan TCP. _Load balancer_ ini mendistribusikan trafik ke seluruh Node _control plane_ pada daftar tujuan. _Health check_ untuk
+ apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver
+ (nilai semula `:6443`).
+
+ - Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada _environment_ cloud.
+
+ - _Load balancer_ harus dapat berkomunikasi dengan seluruh Node _control plane_
+ pada porta yang digunakan apiserver. _Load balancer_ tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya.
+
+ - Pastikan alamat _load balancer_ sesuai
+ dengan alamat `ControlPlaneEndpoint` pada kubeadm.
+
+ - Baca panduan [Opsi untuk _Software Load Balancing_](https://github.com/kubernetes/kubeadm/blob/master/id/docs/ha-considerations.md#options-for-software-load-balancing)
+ untuk detail lebih lanjut.
+
+2. Tambahkan Node _control plane_ pertama pada _load balancer_ dan lakukan pengujian koneksi:
+
+ ```sh
+ nc -v LOAD_BALANCER_IP PORT
+ ```
+
+ - Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum
+ berjalan. Namun jika mendapat _timeout_, berarti _load balancer_ tidak dapat berkomunikasi
+ dengan Node _control plane_. Jika terjadi _timeout_, lakukan pengaturan ulang pada _load balancer_ agar dapat berkomunikasi dengan Node _control plane_.
+
+3. Tambahkan Node _control plane_ lainnya pada grup tujuan _load balancer_.
+
+## Node _control plane_ dan etcd bertumpuk (_stacked_)
+
+### Langkah-langkah untuk Node _control plane_ pertama
+
+1. Inisialisasi _control plane_:
+
+ ```sh
+ sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
+ ```
+
+ - Kamu bisa menggunakan opsi `--kubernetes-version` untuk mengatur versi Kubernetes yang akan digunakan.
+ Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama.
+
+ - Opsi `--control-plane-endpoint` harus diatur menuju alamat atau DNS dan porta dari _load balancer_.
+
+ - Opsi `--upload-certs` digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh
+ Node _control plane_ pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke
+ seluruh Node _control plane_ sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian [Distribusi sertifikat manual](#distribusi-sertifikat-manual) di bawah.
+
+ {{< note >}}
+ Opsi `--config` dan `--certificate-key` pada `kubeadm init` tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan
+ [konfigurasi kubeadm](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
+ kamu harus menambahkan _field_ `certificateKey` pada lokasi pengaturan yang sesuai
+ (berada di bawah `InitConfiguration` dan `JoinConfiguration: controlPlane`).
+ {{< /note >}}
+
+ {{< note >}}
+ Beberapa _plugin_ jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak.
+ Lihat [dokumentasi jaringan CNI](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod).
+ Untuk menambahkan CIDR Pod, tambahkan opsi `--pod-network-cidr`, atau jika kamu menggunakan berkas konfigurasi kubeadm
+ pasang _field_ `podSubnet` di bawah objek `networking` dari `ClusterConfiguration`.
+ {{< /note >}}
+
+ - Keluaran yang dihasilkan terlihat seperti berikut ini:
+
+ ```sh
+ ...
+ You can now join any number of control-plane node by running the following command on each as a root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+
+ Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+ As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+
+ Then you can join any number of worker nodes by running the following on each as root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+ ```
+
+ - Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node _control plane_ dan _worker_ ke klaster.
+ - Ketika opsi `--upload-certs` digunakan dengan `kubeadm init`, sertifikat dari _control plane_ utama
+ akan dienkripsi dan diunggah ke Secret `kubeadm-certs`.
+ - Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node _control plane_
+ yang sudah tergabung pada klaster:
+
+ ```sh
+ sudo kubeadm init phase upload-certs --upload-certs
+ ```
+
+ - Kamu juga dapat menentukan `--certificate-key` _custom_ pada saat `init` yang nanti dapat digunakan pada saat `join`.
+ Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut:
+
+ ```sh
+ kubeadm alpha certs certificate-key
+ ```
+
+ {{< note >}}
+ Secret `kubeadm-certs` dan kunci dekripsi akan kadaluarsa setelah dua jam.
+ {{< /note >}}
+
+ {{< caution >}}
+ Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya!
+ {{< /caution >}}
+
+2. Pasang _plugin_ CNI pilihanmu:
+ [Ikuti petunjuk berikut](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod)
+ untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan.
+
+ Pada contoh berikut kami menggunakan Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+3. Tulis perintah berikut dan saksikan Pod komponen-komponen _control plane_ mulai dinyalakan:
+
+ ```sh
+ kubectl get pod -n kube-system -w
+ ```
+
+### Langkah-langkah selanjutnya untuk Node _control plane_
+
+{{< note >}}
+Sejak kubeadm versi 1.15 kamu dapat menggabungkan beberapa Node _control plane_ secara bersamaan.
+Pada versi sebelumnya, kamu harus menggabungkan Node _control plane_ baru secara berurutan, setelah
+Node pertama selesai diinisialisasi.
+{{< /note >}}
+
+Untuk setiap Node _control plane_ kamu harus:
+
+1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran `kubeadm init` pada Node pertama.
+ Perintah tersebut terlihat seperti ini:
+
+ ```sh
+ sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+ ```
+
+ - Opsi `--control-plane` menunjukkan `kubeadm join` untuk membuat _control plane_ baru.
+ - Opsi `--certificate-key ...` akan membuat sertifikat _control plane_ diunduh
+ dari Secret `kubeadm-certs` pada klaster dan didekripsi menggunakan kunci yang diberikan.
+
+## Node etcd eksternal
+
+Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk
+dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd
+pada berkas konfigurasi kubeadm.
+
+### Memasang klaster etcd
+
+1. Ikuti [petunjuk berikut](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk membangun klaster etcd.
+
+2. Lakukan pengaturan SSH seperti yang dijelaskan [di sini](#distribusi-sertifikat-manual).
+
+3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node _control plane_ pertama:
+
+ ```sh
+ export CONTROL_PLANE="ubuntu@10.0.0.7"
+ scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+ scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
+ ```
+
+ - Ganti nilai `CONTROL_PLANE` dengan `user@host` dari mesin _control plane_ pertama.
+
+### Mengatur Node _control plane_ pertama
+
+1. Buat sebuah berkas bernama `kubeadm-config.yaml` dengan konten sebagai berikut:
+
+ apiVersion: kubeadm.k8s.io/v1beta2
+ kind: ClusterConfiguration
+ kubernetesVersion: stable
+ controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+ etcd:
+ external:
+ endpoints:
+ - https://ETCD_0_IP:2379
+ - https://ETCD_1_IP:2379
+ - https://ETCD_2_IP:2379
+ caFile: /etc/kubernetes/pki/etcd/ca.crt
+ certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+ keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+
+ {{< note >}}
+ Perbedaan antara etcd bertumpuk dan etcd eksternal yaitu etcd eksternal membutuhkan
+ sebuah berkas konfigurasi dengan _endpoint_ etcd di bawah objek `external`untuk `etcd`.
+ Pada kasus ini topologi etcd bertumpuk dikelola secara otomatis.
+ {{< /note >}}
+
+ - Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu:
+
+ - `LOAD_BALANCER_DNS`
+ - `LOAD_BALANCER_PORT`
+ - `ETCD_0_IP`
+ - `ETCD_1_IP`
+ - `ETCD_2_IP`
+
+Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk:
+
+1. Jalankan `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` pada Node ini.
+
+2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti.
+
+3. Pasang _plugin_ CNI pilihanmu. Contoh berikut ini untuk Weave Net:
+
+ ```sh
+ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+ ```
+
+### Langkah selanjutnya untuk Node _control plane_ lainnya
+
+Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk:
+
+- Pastikan Node _control plane_ pertama sudah diinisialisasi dengan sempurna.
+- Gabungkan setiap Node _control plane_ dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk
+menggabungkan Node _control plane_ satu persatu.
+- Jangan lupakan bahwa kunci dekripsi dari `--certificate-key` akan kadaluarsa setelah dua jam, pada pengaturan semula.
+
+## Tugas-tugas umum setelah menyiapkan _control plane_
+
+### Menginstal _worker_
+
+Node _worker_ bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya
+dari keluaran perintah `kubeadm init`:
+
+```sh
+sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+```
+
+## Distribusi sertifikat manual
+
+Jika kamu memilih untuk tidak menggunakan `kubeadm init` dengan opsi `--upload-certs` berarti kamu harus
+menyalin sertifikat dari Node _control plane_ utama secara manual ke
+Node _control plane_ yang akan bergabung.
+
+Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan `ssh` dan `scp`:
+
+SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin.
+
+1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada
+ sistem:
+
+ ```
+ eval $(ssh-agent)
+ ```
+
+2. Tambahkan identitas SSH milikmu ke dalam sesi:
+
+ ```
+ ssh-add ~/.ssh/path_to_private_key
+ ```
+
+3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik.
+
+ - Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi `-A`:
+
+ ```
+ ssh -A 10.0.0.7
+ ```
+
+ - Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan _environment_ yang ada sehingga penerusan SSH
+ dapat bekerja dengan baik:
+
+ ```
+ sudo -E -s
+ ```
+
+4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node _control plane_ pertama setelah
+ menjalankan `kubeadm init`. Skrip ini akan menyalin sertifikat dari Node _control plane_ pertama ke Node
+ _control plane_ lainnya:
+
+ Pada contoh berikut, ganti `CONTROL_PLANE_IPS` dengan alamat IP dari
+ Node _control plane_ lainnya.
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
+ for host in ${CONTROL_PLANE_IPS}; do
+ scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
+ scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
+ scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
+ done
+ ```
+
+ {{< caution >}}
+ Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya
+ dengan SANs yang dibutuhkan untuk Node _control plane_ yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja,
+ pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan.
+ {{< /caution >}}
+
+5. Lalu, pada setiap Node _control plane_ yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan `kubeadm join`.
+ Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori _home_ ke `/etc/kubernetes/pki`:
+
+ ```sh
+ USER=ubuntu # dapat disesuaikan
+ mkdir -p /etc/kubernetes/pki/etcd
+ mv /home/${USER}/ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/sa.pub /etc/kubernetes/pki/
+ mv /home/${USER}/sa.key /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
+ mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
+ mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+ # Kutip baris berikut jika kamu menggunakan etcd eksternal
+ mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
+ ```
+
diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index c81e9f41ec..adcf73db77 100644
--- a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -11,7 +11,7 @@ card:
Laman ini menunjukkan cara untuk menginstal `kubeadm`.
-Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
@@ -132,14 +132,14 @@ Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berh
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{% tab name="sistem operasi lainnya" %}}
Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container.
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{< /tabs >}}
@@ -174,7 +174,7 @@ Hal ini karena kubeadm dan Kubernetes membutuhkan
Untuk informasi lebih lanjut mengenai _version skew_, lihat:
* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
+* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian atau HypriotOS" %}}
@@ -304,4 +304,4 @@ Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyel
## {{% heading "whatsnext" %}}
-* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
+* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md
index 148f402402..6a575ad8f1 100644
--- a/content/id/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md
@@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda
Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`,
yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver.
-Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/).
+Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/).
Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut,
di `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes:
- dapat digunakan untuk menjangkau Node, Pod, atau Service
- melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service
-1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- berjalan di setiap Node
- memproksi UDP dan TCP
diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index b2b80aacba..8775823304 100644
--- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -320,7 +320,7 @@ contexts:
```
Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat
-[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
## Jelajahi direktori $HOME/.kube
@@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 1c6226b1be..d6d04df2ad 100644
--- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -19,7 +19,7 @@ _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigura
Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan
servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
-silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
+silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/)
@@ -35,7 +35,7 @@ silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
## Berkas konfigurasi
Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
-[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu:
```yaml
type: LoadBalancer
diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..f2140e5276
--- /dev/null
+++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,129 @@
+---
+title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster
+content_type: task
+weight: 100
+---
+
+
+
+Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container
+untuk Pod yang berjalan dalam sebuah klaster.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang
+berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar
+Container untuk masing-masing Pod.
+
+## Membuat daftar semua _image_ Container pada semua Namespace
+
+- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces`
+- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container
+ dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_
+ `image` dari keluaran json yang dihasilkan.
+ - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/)
+ untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`.
+- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq`
+ - Gunakan `tr` untuk mengganti spasi dengan garis baru
+ - Gunakan `sort` untuk menyortir hasil
+ - Gunakan `uniq` untuk mengumpulkan jumlah _image_
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image`
+dari semua poin yang dikembalikan.
+
+Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_
+di dalam Pod. Hal ini memastikan _field_ yang diambil benar
+bahkan ketika nama _field_ tersebut diulangi,
+misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+`Jsonpath` dapat diartikan sebagai berikut:
+
+- `.items[*]`: untuk setiap nilai yang dihasilkan
+- `.spec`: untuk mendapatkan spesifikasi
+- `.containers[*]`: untuk setiap Container
+- `.image`: untuk mendapatkan _image_
+
+{{< note >}}
+Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`,
+bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod
+sebagai keluarannya, bukan daftar dari semua Pod.
+
+{{< /note >}}
+
+## Membuat daftar _image_ Container berdasarkan Pod
+
+Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk
+melakukan iterasi untuk setiap elemen secara individual.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Membuat daftar _image_ yang difilter berdasarkan label dari Pod
+
+Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter
+dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod
+
+Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter
+dibawah ini hanya menyaring Pod pada Namespace `kube-system`.
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
+
+Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/)
+untuk memformat keluaran seperti berikut:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Referensi
+
+* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/).
+* Referensi panduan [Go template](https://golang.org/pkg/text/template/).
+
+
+
+
diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
index a83605db40..99d23c823d 100644
--- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai.
_Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
-- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
+- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan.
-- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
+- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
- **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif.
- Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
+ Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
-- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal.
@@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan:
-- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
+- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
-- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
+- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
Contoh:
@@ -107,9 +107,9 @@ track=stable
Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih.
-- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/).
+- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/).
- Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
+ Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih.
@@ -123,7 +123,7 @@ track=stable
### Menggungah berkas YAML atau JSON
-Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/).
+Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/).
Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard.
diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md
new file mode 100644
index 0000000000..0b2ebea7fe
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md
@@ -0,0 +1,177 @@
+---
+title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability)
+content_type: task
+---
+
+
+
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
+
+Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE).
+Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Memulai klaster yang kompatibel dengan HA
+
+Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`:
+
+* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server.
+Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan.
+
+* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru.
+Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd.
+Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat.
+
+Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat.
+Atur tanda berikut:
+
+* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan.
+
+Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b:
+
+```shell
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+```
+
+Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_;
+Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya.
+
+
+## Menambahkan replika _control plane_ yang baru
+
+Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana.
+Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini:
+
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan.
+Region ini harus sama dengan region dari zona replika yang lain.
+
+Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`,
+karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA.
+
+Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA:
+
+```shell
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Menghapus replika _control plane_
+
+Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut:
+
+* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus.
+
+* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus.
+Jika kosong: replika mana saja dari zona yang diberikan akan dihapus.
+
+Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+```
+
+## Mengatasi replika _control plane_ yang gagal
+
+Jika salah satu replika _control plane_ di klaster HA kamu gagal,
+praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama.
+Berikut ini contoh perintah yang menunjukkan proses tersebut:
+
+1. Menghapus replika yang gagal:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
+
+2. Menambahkan replika baru untuk menggantikan replika yang lama
+
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA
+
+* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula.
+Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain
+(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail).
+
+* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten.
+Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas.
+Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal.
+
+* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru.
+Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya.
+Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang).
+
+
+
+
+
+## Catatan implementasi
+
+
+
+### Ikhtisar
+
+Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut:
+
+* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus;
+
+* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia;
+
+* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster;
+
+* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi.
+
+Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka.
+
+
+### Penyeimbang Beban
+
+Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat
+dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban.
+Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada.
+Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan.
+
+
+### Service _control plane_ & kubelet
+
+Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes,
+sistem akan mengarahkan semua lalu lintas ke IP eksternal:
+
+* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal.
+
+* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_.
+
+Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_.
+
+
+### Sertifikat _control plane_
+
+Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika.
+Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika;
+Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS.
+
+### Pengklasteran etcd
+
+Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster).
+Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL.
+
+## Bacaan tambahan
+
+[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
+
+
diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md
new file mode 100644
index 0000000000..409e42dd70
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/namespaces.md
@@ -0,0 +1,302 @@
+---
+title: Membagi sebuah Klaster dengan Namespace
+content_type: task
+---
+
+
+Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu.
+
+
+## {{% heading "prerequisites" %}}
+
+* Memiliki [Klaster Kubernetes](/id/docs/setup/).
+* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes.
+
+
+
+
+## Melihat Namespace
+
+1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan:
+
+```shell
+kubectl get namespaces
+```
+```
+NAME STATUS AGE
+default Active 11d
+kube-system Active 11d
+kube-public Active 11d
+```
+
+Kubernetes mulai dengan tiga Namespace pertama:
+
+ * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain
+ * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes
+ * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan.
+
+Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan:
+
+```shell
+kubectl get namespaces
+```
+
+Atau kamu bisa mendapatkan informasi detail menggunakan:
+
+```shell
+kubectl describe namespaces
+```
+```
+Name: default
+Labels:
+Annotations:
+Status: Active
+
+No resource quota.
+
+Resource Limits
+ Type Resource Min Max Default
+ ---- -------- --- --- ---
+ Container cpu - - 100m
+```
+
+Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya.
+
+Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace.
+
+Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace.
+
+Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
+
+Sebuah Namespace dapat berada dalam salah satu dari dua buah fase:
+
+ * `Active` Namespace sedang digunakan
+ * `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru
+
+Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut.
+
+## Membuat sebuah Namespace baru
+
+{{< note >}}
+ Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes.
+{{< /note >}}
+
+1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini:
+
+ ```yaml
+ apiVersion: v1
+ kind: Namespace
+ metadata:
+ name:
+ ```
+ Then run:
+
+ ```
+ kubectl create -f ./my-namespace.yaml
+ ```
+
+2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini:
+
+ ```
+ kubectl create namespace
+ ```
+
+Nama Namespace kamu harus merupakan
+[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid.
+
+Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya.
+
+Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace.
+
+## Menghapus Namespace
+
+Hapus Namespace dengan
+
+```shell
+kubectl delete namespaces
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup
Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 4d3a9255d4..d7fc53a4d0 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -235,7 +235,7 @@ IngressClass resource will ensure that new Ingresses without an If you have more than one IngressClass marked as the default for your cluster, the admission controller prevents creating new Ingress objects that don't have an `ingressClassName` specified. You can resolve this by ensuring that at most 1 -IngressClasess are marked as default in your cluster. +IngressClasses are marked as default in your cluster. {{< /caution >}} ## Types of Ingress diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 79d260d52a..9819334ce8 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1356,7 +1356,7 @@ persistent volume: of a volume. This map must correspond to the map returned in the `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The map is passed to the CSI driver via the `volume_attributes` field in the + The map is passed to the CSI driver via the `volume_context` field in the `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. - `controllerPublishSecretRef`: A reference to the secret object containing diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 7f1b5c4630..c3d8cf36d8 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev The `.spec.template` is one of the required fields in `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 67582e9041..2c2fd8c7c2 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -13,8 +13,8 @@ weight: 30 -A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and -[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). +A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} +{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. @@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th {{< /note >}} - - ## Use Case @@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib The `.spec.template` and `.spec.selector` are the only required field of the `.spec`. -The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an -`apiVersion` or `kind`. +The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)). @@ -1155,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). -### Rollback To - -Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used. - ### Revision History Limit A Deployment's revision history is stored in the ReplicaSets it controls. diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index a20951a35e..79cc905f58 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy` field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan", "Foreground", or "Background". -Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`. -This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and -Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you -specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` -group version, dependent objects are deleted by default. - Here's an example that deletes dependents in background: ```shell diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 21e8aceb64..81c1280943 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index 2cc8284940..d59c09fc6b 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector). diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 index a105f18fb3..c7408721b7 --- a/content/en/docs/concepts/workloads/pods/_index.md +++ b/content/en/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,271 @@ --- -title: "Pods" +reviewers: +- erictune +title: Pods +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + + +_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes. + +A _Pod_ (as in a pod of whales or pea pod) is a group of one or more +{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification +for how to run the containers. A Pod's contents are always co-located and +co-scheduled, and run in a shared context. A Pod models an +application-specific "logical host": it contains one or more application +containers which are relatively tightly coupled. +In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. + +As well as application containers, a Pod can contain +[init containers](/docs/concepts/workloads/pods/init-containers/) that run +during Pod startup. You can also inject +[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) +for debugging if your cluster offers this. + + + +## What is a Pod? + +{{< note >}} +While Kubernetes supports more +{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} +than just Docker, [Docker](https://www.docker.com/) is the most commonly known +runtime, and it helps to describe Pods using some terminology from Docker. +{{< /note >}} + +The shared context of a Pod is a set of Linux namespaces, cgroups, and +potentially other facets of isolation - the same things that isolate a Docker +container. Within a Pod's context, the individual applications may have +further sub-isolations applied. + +In terms of Docker concepts, a Pod is similar to a group of Docker containers +with shared namespaces and shared filesystem volumes. + +## Using Pods + +Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment" +term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}. +If your Pods need to track state, consider the +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource. + +Pods in a Kubernetes cluster are used in two main ways: + +* **Pods that run a single container**. The "one-container-per-Pod" model is the + most common Kubernetes use case; in this case, you can think of a Pod as a + wrapper around a single container; Kubernetes manages Pods rather than managing + the containers directly. +* **Pods that run multiple containers that need to work together**. A Pod can + encapsulate an application composed of multiple co-located containers that are + tightly coupled and need to share resources. These co-located containers + form a single cohesive unit of service—for example, one container serving data + stored in a shared volume to the public, while a separate _sidecar_ container + refreshes or updates those files. + The Pod wraps these containers, storage resources, and an ephemeral network + identity together as a single unit. + + {{< note >}} + Grouping multiple co-located and co-managed containers in a single Pod is a + relatively advanced use case. You should use this pattern only in specific + instances in which your containers are tightly coupled. + {{< /note >}} + +Each Pod is meant to run a single instance of a given application. If you want to +scale your application horizontally (to provide more overall resources by running +more instances), you should use multiple Pods, one for each instance. In +Kubernetes, this is typically referred to as _replication_. +Replicated Pods are usually created and managed as a group by a workload resource +and its {{< glossary_tooltip text="controller" term_id="controller" >}}. + +See [Pods and controllers](#pods-and-controllers) for more information on how +Kubernetes uses workload resources, and their controllers, to implement application +scaling and auto-healing. + +### How Pods manage multiple containers + +Pods are designed to support multiple cooperating processes (as containers) that form +a cohesive unit of service. The containers in a Pod are automatically co-located and +co-scheduled on the same physical or virtual machine in the cluster. The containers +can share resources and dependencies, communicate with one another, and coordinate +when and how they are terminated. + +For example, you might have a container that +acts as a web server for files in a shared volume, and a separate "sidecar" container +that updates those files from a remote source, as in the following diagram: + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. + +Pods natively provide two kinds of shared resources for their constituent containers: +[networking](#pod-networking) and [storage](#pod-storage). + +## Working with Pods + +You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This +is because Pods are designed as relatively ephemeral, disposable entities. When +a Pod gets created (directly by you, or indirectly by a +{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is +scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. +The Pod remains on that node until the Pod finishes execution, the Pod object is deleted, +the Pod is *evicted* for lack of resources, or the node fails. + +{{< note >}} +Restarting a container in a Pod should not be confused with restarting a Pod. A Pod +is not a process, but an environment for running container(s). A Pod persists until +it is deleted. +{{< /note >}} + +When you create the manifest for a Pod object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Pods and controllers + +You can use workload resources to create and manage multiple Pods for you. A controller +for the resource handles replication and rollout and automatic healing in case of +Pod failure. For example, if a Node fails, a controller notices that Pods on that +Node have stopped working and creates a replacement Pod. The scheduler places the +replacement Pod onto a healthy Node. + +Here are some examples of workload resources that manage one or more Pods: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod templates + +Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods +from a _pod template_ and manage those Pods on your behalf. + +PodTemplates are specifications for creating Pods, and are included in workload resources such as +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Each controller for a workload resource uses the `PodTemplate` inside the workload +object to make actual Pods. The `PodTemplate` is part of the desired state of whatever +workload resource you used to run your app. + +The sample below is a manifest for a simple Job with a `template` that starts one +container. The container in that Pod prints a message then pauses. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # This is the pod template + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # The pod template ends here +``` + +Modifying the pod template or switching to a new pod template has no effect on the +Pods that already exist. Pods do not receive template updates directly. Instead, +a new Pod is created to match the revised pod template. + +For example, the deployment controller ensures that the running Pods match the current +pod template for each Deployment object. If the template is updated, the Deployment has +to remove the existing Pods and create new Pods based on the updated template. Each workload +resource implements its own rules for handling changes to the Pod template. + +On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not +directly observe or manage any of the details around pod templates and updates; those +details are abstracted away. That abstraction and separation of concerns simplifies +system semantics, and makes it feasible to extend the cluster's behavior without +changing existing code. + +## Resource sharing and communication + +Pods enable data sharing and communication among their constituent +containters. + +### Storage in Pods {#pod-storage} + +A Pod can specify a set of shared storage +{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers +in the Pod can access the shared volumes, allowing those containers to +share data. Volumes also allow persistent data in a Pod to survive +in case one of the containers within needs to be restarted. See +[Storage](/docs/concepts/storage/) for more information on how +Kubernetes implements shared storage and makes it available to Pods. + +### Pod networking + +Each Pod is assigned a unique IP address for each address family. Every +container in a Pod shares the network namespace, including the IP address and +network ports. Inside a Pod (and **only** then), the containers that belong to the Pod +can communicate with one another using `localhost`. When containers in a Pod communicate +with entities *outside the Pod*, +they must coordinate how they use the shared network resources (such as ports). +Within a Pod, containers share an IP address and port space, and +can find each other via `localhost`. The containers in a Pod can also communicate +with each other using standard inter-process communications like SystemV semaphores +or POSIX shared memory. Containers in different Pods have distinct IP addresses +and can not communicate by IPC without +[special configuration](/docs/concepts/policy/pod-security-policy/). +Containers that want to interact with a container running in a different Pod can +use IP networking to comunicate. + +Containers within the Pod see the system hostname as being the same as the configured +`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) +section. + +## Privileged mode for containers + +Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. +Processes within a privileged container get almost the same privileges that are available to processes outside a container. + +{{< note >}} +Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. +{{< /note >}} + +## Static Pods + +_Static Pods_ are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Whereas most Pods are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static +Pods, the kubelet directly supervises each static Pod (and restarts it if it fails). + +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +The main use for static Pods is to run a self-hosted control plane: in other words, +using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components). + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. + +## {{% heading "whatsnext" %}} + +* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). +* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/). +* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to + configure different Pods with different container runtime configurations. +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. +* Pod is a top-level resource in the Kubernetes REST API. + The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + object definition describes the object in detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container. + +To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including: + * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 589bde5668..0810b6fec7 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -11,17 +11,15 @@ weight: 60 This guide is for application owners who want to build highly available applications, and thus need to understand -what types of Disruptions can happen to Pods. +what types of disruptions can happen to Pods. -It is also for Cluster Administrators who want to perform automated +It is also for cluster administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. - - -## Voluntary and Involuntary Disruptions +## Voluntary and involuntary disruptions Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error. @@ -48,7 +46,7 @@ Administrator. Typical application owner actions include: - updating a deployment's pod template causing a restart - directly deleting a pod (e.g. by accident) -Cluster Administrator actions include: +Cluster administrator actions include: - [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade. - Draining a node from a cluster to scale the cluster down (learn about @@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa deleting deployments or pods bypasses Pod Disruption Budgets. {{< /caution >}} -## Dealing with Disruptions +## Dealing with disruptions Here are some ways to mitigate involuntary disruptions: @@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. -Kubernetes offers features to help run highly available applications at the same -time as frequent voluntary disruptions. We call this set of features -*Disruption Budgets*. - -## How Disruption Budgets Work +## Pod disruption budgets {{< feature-state for_k8s_version="v1.5" state="beta" >}} -An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. -A PDB limits the number of pods of a replicated application that are down simultaneously from -voluntary disruptions. For example, a quorum-based application would +Kubernetes offers features to help you run highly available applications even when you +introduce frequent voluntary disruptions. + +As an application owner, you can create a PodDisruptionBudget (PDB) for each application. +A PDB limits the number of Pods of a replicated application that are down simultaneously from +voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) -instead of directly deleting pods or deployments. Examples are the `kubectl drain` command -and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`). +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +instead of directly deleting pods or deployments. -When a cluster administrator wants to drain a node -they use the `kubectl drain` command. That tool tries to evict all -the pods on the machine. The eviction request may be temporarily rejected, -and the tool periodically retries all failed requests until all pods -are terminated, or until a configurable timeout is reached. +For example, the `kubectl drain` subcommand lets you mark a node as going out of +service. When you run `kubectl drain`, the tool tries to evict all of the Pods on +the Node you're taking out of service. The eviction request that `kubectl` submits on +your behalf may be temporarily rejected, so the tool periodically retries all failed +requests until all Pods on the target node are terminated, or until a configurable timeout +is reached. A PDB specifies the number of replicas that an application can tolerate having, relative to how many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, -then the Eviction API will allow voluntary disruption of one, but not two pods, at a time. +then the Eviction API will allow voluntary disruption of one (but not two) pods at a time. The group of pods that comprise the application is specified using a label selector, the same as the one used by the application's controller (deployment, stateful-set, etc). -The "intended" number of pods is computed from the `.spec.replicas` of the pods controller. -The controller is discovered from the pods using the `.metadata.ownerReferences` of the object. +The "intended" number of pods is computed from the `.spec.replicas` of the workload resource +that is managing those pods. The control plane discovers the owning workload resource by +examining the `.metadata.ownerReferences` of the Pod. PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from occurring, but they do count against the budget. Pods which are deleted or unavailable due to a rolling upgrade to an application do count -against the disruption budget, but controllers (like deployment and stateful-set) -are not limited by PDBs when doing rolling upgrades -- the handling of failures -during application updates is configured in the controller spec. -(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +against the disruption budget, but workload resources (such as Deployment and StatefulSet) +are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures +during application updates is configured in the spec for the specific workload resource. -When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) +When a pod is evicted using the eviction API, it is gracefully +[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the +`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) -## PDB Example +## PodDisruptionBudget example {#pdb-example} Consider a cluster with 3 nodes, `node-1` through `node-3`. The cluster is running several applications. One of them has 3 replicas initially called @@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) +* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + including steps to maintain its availability during the rollout. diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index d72265faf5..2b292d376d 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,16 +6,60 @@ weight: 30 -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} - -This page describes the lifecycle of a Pod. +This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting +in the `Pending` [phase](#pod-phase), moving through `Running` if at least one +of its primary containers starts OK, and then through either the `Succeeded` or +`Failed` phases depending on whether any container in the Pod terminated in failure. +Whilst a Pod is running, the kubelet is able to restart containers to handle some +kind of faults. Within a Pod, Kubernetes tracks different container +[states](#container-states) and handles +In the Kubernetes API, Pods have both a specification and an actual status. The +status for a Pod object consists of a set of [Pod conditions](#pod-conditions). +You can also inject [custom readiness information](#pod-readiness-gate) into the +condition data for a Pod, if that is useful to your application. +Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime. +Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops +or is [terminated](#pod-termination). +## Pod lifetime + +Like individual application containers, Pods are considered to be relatively +ephemeral (rather than durable) entities. Pods are created, assigned a unique +ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled +to nodes where they remain until termination (according to restart policy) or +deletion. +If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node +are [scheduled for deletion](#pod-garbage-collection) after a timeout period. + +Pods do not, by themselves, self-heal. If a Pod is scheduled to a +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, +or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a +higher-level abstraction, called a +{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of +managing the relatively disposable Pod instances. + +A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, +that Pod can be replaced by a new, near-identical Pod, with even the same name i +desired, but with a different UID. + +When something is said to have the same lifetime as a Pod, such as a +{{< glossary_tooltip term_id="volume" text="volume" >}}, +that means that the thing exists as long as that specific Pod (with that exact UID) +exists. If that Pod is deleted for any reason, and even if an identical replacement +is created, the related thing (a volume, in this example) is also destroyed and +created anew. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*A multi-container Pod that contains a file puller and a +web server that uses a persistent volume for shared storage between the containers.* + ## Pod phase A Pod's `status` field is a @@ -24,7 +68,7 @@ object, which has a `phase` field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations -of Container or Pod state, nor is it intended to be a comprehensive state machine. +of container or Pod state, nor is it intended to be a comprehensive state machine. The number and meanings of Pod phase values are tightly guarded. Other than what is documented here, nothing should be assumed about Pods that @@ -34,188 +78,106 @@ Here are the possible values for `phase`: Value | Description :-----|:----------- -`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting. -`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted. -`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system. -`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod. +`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network. +`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. +`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. +`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. +`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Container states + +As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of +each container inside a Pod. You can use +[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to +trigger events to run at certain points in a container's lifecycle. + +Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} +assigns a Pod to a Node, the kubelet starts creating containers for that Pod +using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +There are three possible container states: `Waiting`, `Running`, and `Terminated`. + +To the check state of a Pod's containers, you can use +`kubectl describe pod
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md
deleted file mode 100644
index f4cca67155..0000000000
--- a/content/en/docs/contribute/participate/roles-and-responsibilties.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Roles and responsibilities
-content_type: concept
-weight: 10
----
-
-
-
-Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
-These roles allow you to take on more responsibility within the community.
-Each role requires more time and commitment. The roles are:
-
-- Anyone: regular contributors to the Kubernetes documentation
-- Members: can assign and triage issues and provide non-binding review on pull requests
-- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
-- Approvers: can lead reviews on documentation and merge changes
-
-
-
-## Anyone
-
-Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
-
-Anyone can:
-
-- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
-- Give non-binding feedback on a pull request
-- Contribute to a localization
-- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-
-- Open a pull request to improve existing content, add new content, or write a blog post or case study
-- Create diagrams, graphics assets, and embeddable screencasts and videos
-
-For more information, see [contributing new content](/docs/contribute/new-content/).
-
-## Members
-
-A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
-
-Members can:
-
-- Do everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
-
- {{< note >}}
- Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too!
- {{< /note >}}
-- Use the `/hold` comment to block merging for a pull request
-- Use the `/assign` comment to assign a reviewer to a pull request
-- Provide non-binding review on pull requests
-- Use automation to triage and categorize issues
-- Document new features
-
-### Becoming a member
-
-After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
-
-1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
-
- Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member. You must request sponsorship before submitting your application.
- {{< /note >}}
-
-2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-
-3. Let your sponsors know about the GitHub issue. You can either:
- - Mention their GitHub username in an issue (`@
-
-- Visit the Netlify page preview for a PR to make sure things look good before approving.
-
-- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/).
-for more details.
-
-### Becoming an approver
-
-When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
-
-To apply:
-
-1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository.
-
- {{< note >}}
- If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
- {{< /note >}}
-
-2. Assign the PR to one or more current SIG Docs approvers.
-
-If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-
-## {{% heading "whatsnext" %}}
-
-- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
\ No newline at end of file
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 0cddbcba6a..82a05bdb86 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -8,7 +8,9 @@ weight: 20
-SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
+SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
+[Approvers](/docs/contribute/participate/#approvers) do a few extra things
+when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -19,9 +21,6 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-
-
-
## Reviewing a PR
@@ -202,9 +201,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
-[Kubernetes slack](http://slack.k8s.io/). You can also search
+[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index 3c271aa44f..ff6ef9d709 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
-[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-
-
+ [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Understand the different
+ [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/)
+ in the Kubernetes documentation community.
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index 569ca8d72c..0de4a381a3 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -10,9 +10,9 @@ weight: 10
This page contains guidelines for Kubernetes documentation.
If you have questions about what's allowed, join the #sig-docs channel in
-[Kubernetes Slack](http://slack.k8s.io/) and ask!
+[Kubernetes Slack](https://slack.k8s.io/) and ask!
-You can register for Kubernetes Slack at http://slack.k8s.io/.
+You can register for Kubernetes Slack at https://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
@@ -67,7 +67,7 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes
### More information
-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
+If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index e4a6d703ad..ab949be7fc 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -232,7 +232,7 @@ Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
-{{< tab name="JSON File" include="podtemplate" />}}
+{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
@@ -242,6 +242,6 @@ Renders to:
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/contribute/style/page-content-types/).
-* Learn about [creating a pull request](/docs/contribute/new-content/new-content/).
+* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
index 2a3325d397..5d3b519bc0 100644
--- a/content/en/docs/contribute/style/page-content-types.md
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines:
interested in reading next.
An example of a published tutorial topic is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
### Reference
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 55aa30d66c..44653708ec 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -22,8 +22,11 @@ discussion.
{{< note >}}
-Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
-and representing feature state.
+Kubernetes documentation uses
+[Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
+with some adjustments along with a few
+[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support
+glossary entries, tabs, and representing feature state.
{{< /note >}}
## Language
@@ -584,12 +587,8 @@ The Federation feature provides ... | The new Federation feature provides ...
{{< /table >}}
-
-
## {{% heading "whatsnext" %}}
-
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [using page templates](/docs/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 3e4f999c08..7cac1aa6b7 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs.
## {{% heading "prerequisites" %}}
Create a fork of the Kubernetes documentation repository as described in
-[Open a PR](/docs/new-content/open-a-pr/).
+[Open a PR](/docs/contribute/new-content/open-a-pr/).
@@ -160,7 +160,7 @@ submitted to ensure all examples pass the tests.
{{< /note >}}
For an example of a topic that uses this technique, see
-[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
+[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/).
## Adding images to a topic
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index c0747f3d56..7e1f8ced66 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -677,9 +677,6 @@ for more information.
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
for more information.
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index d196be938d..398f06b671 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 1227f750eb..a9db3b00eb 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -997,7 +997,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
### Matching requests: matchPolicy
API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 20b1224e59..2be833826c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation.
| Default ClusterRole | Default ClusterRoleBinding | Description | |
|---|---|---|---|
| system:basic-user | system:authenticated group | @@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation.system:authenticated and system:unauthenticated groups | Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14. |
| Default ClusterRole | Default ClusterRoleBinding | Description |
|---|---|---|
| cluster-admin | system:masters group | @@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation).
| Default ClusterRole | Default ClusterRoleBinding | Description | |
|---|---|---|---|
| system:kube-scheduler | system:kube-scheduler user | @@ -733,17 +744,21 @@ The system:node role only exists for compatibility with Kubernetes clussystem:kube-proxy user | Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component. |
| Default ClusterRole | Default ClusterRoleBinding | Description | |
|---|---|---|---|
| system:auth-delegator | None | @@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and authoNone | Allows access to the resources required by most dynamic volume provisioners. |
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
-(CNI) based Pod network add-on so that your Pods can communicate with each other.
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
- networks: you are likely to see problems if there is any overlap.
+ networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
@@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
- control).
+ control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
- supports IPv6.
+ supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
{{< /caution >}}
@@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers.
{{< /note >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
-See the list of available
-[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
@@ -297,79 +297,6 @@ kubectl apply -f - A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods. + A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
Overview of Kubernetes Services
-Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
+Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index 63e7b4b3af..aa2ee52152 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya. -[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini @@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya. ### Web UI (Dasbor) -[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. +[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun aplikasi yang ada pada klaster itu sendiri. @@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan. ### Cluster-level Logging -[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada +[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian. diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md index 9599feaf24..46066769d4 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut: -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan dalam dokumen ini: @@ -862,8 +862,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md index e77cc9ca63..23489efb59 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md index 7df68f579d..94f1082e35 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -108,8 +108,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md index 8a822f255d..aaa238add5 100644 --- a/content/id/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md @@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku ## {{% heading "whatsnext" %}} -Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/). +Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/). diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md index 7cd81495cd..e46916ee3d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,14 +3,14 @@ title: Selektor Field weight: 60 --- -Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan +Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*: * `metadata.name=my-service` * `metadata.namespace!=default` * `status.phase=Pending` -Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai +Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai `Running`: ```shell @@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default ## Selektor berantai -Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai +Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai (*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan `Running` dan *field* `spec.restartPolicy` sama dengan `Always`: diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 57eef5e9c6..aa702827b9 100644 --- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan. Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu -harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). +harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/). Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan. @@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/). +* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/). diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md index 5527c15b72..0d6528c41d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/names.md +++ b/content/id/docs/concepts/overview/working-with-objects/names.md @@ -8,7 +8,7 @@ weight: 20 Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID. -Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/). +Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/). Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID. diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md index 5eb358a17a..89ffb8ea14 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster *Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*. -*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). +*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)). Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*. @@ -74,7 +74,7 @@ kubectl config view | grep namespace: ## Namespace dan DNS -Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `
Laman ini menunjukkan cara untuk menginstal `kubeadm`.
-Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
@@ -132,14 +132,14 @@ Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berh
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{% tab name="sistem operasi lainnya" %}}
Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container.
Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya.
-Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/)
+Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/)
untuk informasi lebih lanjut.
{{% /tab %}}
{{< /tabs >}}
@@ -174,7 +174,7 @@ Hal ini karena kubeadm dan Kubernetes membutuhkan
Untuk informasi lebih lanjut mengenai _version skew_, lihat:
* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/)
-* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
+* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian atau HypriotOS" %}}
@@ -304,4 +304,4 @@ Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyel
## {{% heading "whatsnext" %}}
-* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
+* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md
index 148f402402..6a575ad8f1 100644
--- a/content/id/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md
@@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda
Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`,
yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver.
-Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/).
+Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/).
Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut,
di `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes:
- dapat digunakan untuk menjangkau Node, Pod, atau Service
- melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service
-1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- berjalan di setiap Node
- memproksi UDP dan TCP
diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index b2b80aacba..8775823304 100644
--- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -320,7 +320,7 @@ contexts:
```
Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat
-[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
## Jelajahi direktori $HOME/.kube
@@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 1c6226b1be..d6d04df2ad 100644
--- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -19,7 +19,7 @@ _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigura
Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan
servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll.,
-silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
+silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/)
@@ -35,7 +35,7 @@ silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/)
## Berkas konfigurasi
Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke
-[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu:
+[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu:
```yaml
type: LoadBalancer
diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..f2140e5276
--- /dev/null
+++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,129 @@
+---
+title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster
+content_type: task
+weight: 100
+---
+
+
+
+Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container
+untuk Pod yang berjalan dalam sebuah klaster.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang
+berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar
+Container untuk masing-masing Pod.
+
+## Membuat daftar semua _image_ Container pada semua Namespace
+
+- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces`
+- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container
+ dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_
+ `image` dari keluaran json yang dihasilkan.
+ - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/)
+ untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`.
+- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq`
+ - Gunakan `tr` untuk mengganti spasi dengan garis baru
+ - Gunakan `sort` untuk menyortir hasil
+ - Gunakan `uniq` untuk mengumpulkan jumlah _image_
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image`
+dari semua poin yang dikembalikan.
+
+Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_
+di dalam Pod. Hal ini memastikan _field_ yang diambil benar
+bahkan ketika nama _field_ tersebut diulangi,
+misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+`Jsonpath` dapat diartikan sebagai berikut:
+
+- `.items[*]`: untuk setiap nilai yang dihasilkan
+- `.spec`: untuk mendapatkan spesifikasi
+- `.containers[*]`: untuk setiap Container
+- `.image`: untuk mendapatkan _image_
+
+{{< note >}}
+Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`,
+bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod
+sebagai keluarannya, bukan daftar dari semua Pod.
+
+{{< /note >}}
+
+## Membuat daftar _image_ Container berdasarkan Pod
+
+Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk
+melakukan iterasi untuk setiap elemen secara individual.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Membuat daftar _image_ yang difilter berdasarkan label dari Pod
+
+Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter
+dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`.
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod
+
+Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter
+dibawah ini hanya menyaring Pod pada Namespace `kube-system`.
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
+
+Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/)
+untuk memformat keluaran seperti berikut:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Referensi
+
+* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/).
+* Referensi panduan [Go template](https://golang.org/pkg/text/template/).
+
+
+
+
diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
index a83605db40..99d23c823d 100644
--- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai.
_Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
-- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
+- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan.
-- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
+- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
- **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif.
- Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
+ Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
-- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal.
@@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan:
-- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
+- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
-- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
+- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
Contoh:
@@ -107,9 +107,9 @@ track=stable
Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih.
-- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/).
+- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/).
- Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
+ Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih.
@@ -123,7 +123,7 @@ track=stable
### Menggungah berkas YAML atau JSON
-Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/).
+Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/).
Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard.
diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md
new file mode 100644
index 0000000000..0b2ebea7fe
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md
@@ -0,0 +1,177 @@
+---
+title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability)
+content_type: task
+---
+
+
+
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
+
+Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE).
+Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Memulai klaster yang kompatibel dengan HA
+
+Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`:
+
+* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server.
+Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan.
+
+* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru.
+Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd.
+Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat.
+
+Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat.
+Atur tanda berikut:
+
+* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan.
+
+Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b:
+
+```shell
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+```
+
+Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_;
+Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya.
+
+
+## Menambahkan replika _control plane_ yang baru
+
+Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana.
+Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini:
+
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan.
+Region ini harus sama dengan region dari zona replika yang lain.
+
+Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`,
+karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA.
+
+Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA:
+
+```shell
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Menghapus replika _control plane_
+
+Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut:
+
+* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet.
+
+* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus.
+
+* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus.
+Jika kosong: replika mana saja dari zona yang diberikan akan dihapus.
+
+Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+```
+
+## Mengatasi replika _control plane_ yang gagal
+
+Jika salah satu replika _control plane_ di klaster HA kamu gagal,
+praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama.
+Berikut ini contoh perintah yang menunjukkan proses tersebut:
+
+1. Menghapus replika yang gagal:
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
+
+2. Menambahkan replika baru untuk menggantikan replika yang lama
+
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA
+
+* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula.
+Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain
+(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail).
+
+* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten.
+Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas.
+Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal.
+
+* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru.
+Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya.
+Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang).
+
+
+
+
+
+## Catatan implementasi
+
+
+
+### Ikhtisar
+
+Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut:
+
+* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus;
+
+* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia;
+
+* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster;
+
+* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi.
+
+Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka.
+
+
+### Penyeimbang Beban
+
+Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat
+dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban.
+Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada.
+Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan.
+
+
+### Service _control plane_ & kubelet
+
+Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes,
+sistem akan mengarahkan semua lalu lintas ke IP eksternal:
+
+* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal.
+
+* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_.
+
+Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_.
+
+
+### Sertifikat _control plane_
+
+Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika.
+Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika;
+Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS.
+
+### Pengklasteran etcd
+
+Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster).
+Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL.
+
+## Bacaan tambahan
+
+[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
+
+
diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md
new file mode 100644
index 0000000000..409e42dd70
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/namespaces.md
@@ -0,0 +1,302 @@
+---
+title: Membagi sebuah Klaster dengan Namespace
+content_type: task
+---
+
+
+Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu.
+
+
+## {{% heading "prerequisites" %}}
+
+* Memiliki [Klaster Kubernetes](/id/docs/setup/).
+* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes.
+
+
+
+
+## Melihat Namespace
+
+1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan:
+
+```shell
+kubectl get namespaces
+```
+```
+NAME STATUS AGE
+default Active 11d
+kube-system Active 11d
+kube-public Active 11d
+```
+
+Kubernetes mulai dengan tiga Namespace pertama:
+
+ * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain
+ * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes
+ * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan.
+
+Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan:
+
+```shell
+kubectl get namespaces