kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.23

This commit is contained in:
Jesse Butler 2021-12-06 08:55:54 -05:00
parent 3d07786e5d b904695d10
commit 584421fe11
152 changed files with 1691 additions and 942 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
assets/scss/_custom.scss
View File

@ -601,7 +601,7 @@ body.td-documentation {
#announcement {
> * {
color: inherit;
background: inherit;
background: transparent;
}
a {
@ -765,3 +765,24 @@ dl {
margin-top: 1.5em;
}
}
.release-details {
padding-left: 2em;
> :not(p) {
font-size: 1.125em;
}
.release-inline-heading, .release-inline-value {
display: inline-block
}
.release-inline-value {
padding-left: 0.25em;
}
p {
margin-top: 1em;
margin-bottom: 1em;
}
}

10
content/en/_index.html
View File

@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

2
content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md
View File

@ -28,7 +28,7 @@ metadata:
name: shared-cache
spec:
accessModes:
- ReadWriteMany # Allow many pods to access shared-cache simultaneously.
- ReadWriteMany # Allow many nodes to access shared-cache simultaneously.
resources:
requests:
storage: 1Gi

343
content/en/blog/_posts/2021-12-01-kubernetes-1.22-release-interview.md Normal file
View File

@ -0,0 +1,343 @@
---
layout: blog
title: "Contribution, containers and cricket: the Kubernetes 1.22 release interview"
date: 2021-12-01
---
**Author**: Craig Box (Google)
The Kubernetes release train rolls on, and we look ahead to the release of 1.23 next week. [As is our tradition](https://www.google.com/search?q=%22release+interview%22+site%3Akubernetes.io%2Fblog), I'm pleased to bring you a look back at the process that brought us the previous version.
The release team for 1.22 was led by [Savitha Raghunathan](https://twitter.com/coffeeartgirl), who was, at the time, a Senior Platform Engineer at MathWorks. [I spoke to Savitha](https://kubernetespodcast.com/episode/157-kubernetes-1.22/) on the [Kubernetes Podcast from Google](https://kubernetespodcast.com/), the weekly<super>*</super> show covering the Kubernetes and Cloud Native ecosystem.
Our release conversations shine a light on the team that puts together each Kubernetes release. Make sure you [subscribe, wherever you get your podcasts](https://kubernetespodcast.com/subscribe/) so you catch the story of 1.23.
And in case you're interested in why the show has been on a hiatus the last few weeks, all will be revealed in the next episode!
*This transcript has been lightly edited and condensed for clarity.*
---
**CRAIG BOX: Welcome to the show, Savitha.**
SAVITHA RAGHUNATHAN: Hey, Craig. Thanks for having me on the show. How are you today?
**CRAIG BOX: I'm very well, thank you. I've interviewed a lot of people on the show, and you're actually the first person who's asked that of me.**
SAVITHA RAGHUNATHAN: I'm glad. It's something that I always do. I just want to make sure the other person is good and happy.
**CRAIG BOX: That's very kind of you. Thank you for kicking off on a wonderful foot there. I want to ask first of all — you grew up in Chennai. My association with Chennai is the [Super Kings cricket team](https://en.wikipedia.org/wiki/Chennai_Super_Kings). Was cricket part of your upbringing?**
SAVITHA RAGHUNATHAN: Yeah. Actually, a lot. My mom loves watching cricket. I have a younger brother, and when we were growing up, we used to play cricket on the terrace. Everyone surrounding me, my best friends — and even now, my partner — loves watching cricket, too. Cricket is a part of my life.
I stopped watching it a while ago, but I still enjoy a good game.
**CRAIG BOX: It's probably a bit harder in the US. Everything's in a different time zone. I find, with my cricket team being on the other side of the world, that it's a lot easier when they're playing near me, as opposed to trying to keep up with what they're doing when they're playing at 3:00 in the morning.**
SAVITHA RAGHUNATHAN: That is actually one of the things that made me lose touch with cricket. I'm going to give you a piece of interesting information. I never supported Chennai Super Kings. I always supported [Royal Challengers of Bangalore](https://en.wikipedia.org/wiki/Royal_Challengers_Bangalore).
I once went to the stadium, and it was a match between the Chennai Super Kings and the RCB. I was the only one who was cheering whenever the RCB hit a 6, or when they were scoring. I got the stares of thousands of people looking at me. I'm like, "what are you doing?" My friends are like, "you're going to get us killed! Just stop screaming!"
**CRAIG BOX: I hear you. As a New Zealander in the UK, there are a lot of international cricket matches I've been to where I am one of the few people dressed in the full beige kit. But I have to ask, why an affiliation with a different team?**
SAVITHA RAGHUNATHAN: I'm not sure. When the IPL came out, I really liked Virat Kohli. He was playing for RCB at that time, and I think pretty much that's it.
**CRAIG BOX: Well, what I know about the Chennai Super Kings is that their coach is New Zealand's finest batsmen and [air conditioning salesman](https://www.youtube.com/watch?v=vSZAaUCAclw), [Stephen Fleming](https://en.wikipedia.org/wiki/Stephen_Fleming).**
SAVITHA RAGHUNATHAN: Oh, really?
**CRAIG BOX: Yeah, he's a dead ringer for the guy who played the [yellow Wiggle](https://s1.reutersmedia.net/resources/r/?m=02&d=20061130&t=2&i=153531&w=&fh=545px&fw=&ll=&pl=&sq=&r=153531) back in the day.**
SAVITHA RAGHUNATHAN: Oh, interesting. I remember the name, but I cannot put the picture and the name together. I stopped watching cricket once I moved to the States. Then, all my focus was on studies and extracurriculars. I have always been an introvert. The campus — it was a new thing for me — they had international festivals.
And every week, they'd have some kind of new thing going on, so I'd go check them out. I wouldn't participate, but I did go out and check them out. That was a big feat for me around that time because a lot of people — and still, even now, a lot of people — they kind of scare me. I don't know how to make a conversation with everyone.
I'll just go and say, "hi, how are you? OK, I'm good. I'm just going to move on". And I'll just go to the next person. And after two hours, I'm out of that place.
**CRAIG BOX: Perhaps a pleasant side effect of the last 12 months — a lot fewer gatherings of people.**
SAVITHA RAGHUNATHAN: Could be that, but I'm so excited about KubeCon. But when I think about it, I'm like "oh my God. There's going to be a lot of people. What am I going to do? I'm going to meet all my friends over there".
Sometimes I have social anxiety like, what's going to happen?
**CRAIG BOX: What's going to happen is you're going to ask them how they are at the beginning, and they're immediately going to be set at ease.**
SAVITHA RAGHUNATHAN: *laughs* I hope so.
**CRAIG BOX: Let's talk a little bit, then, about your transition from India to the US. You did your undergraduate degree in computer science at the SSN College of Engineering. How did you end up at Arizona State?**
SAVITHA RAGHUNATHAN: I always wanted to pursue higher studies when I was in India, and I didn't have the opportunity immediately. Once I graduated from my school there, I went and I worked for a couple of years. My aim was always to get out of there and come here, do my graduate studies.
Eventually, I want to do a PhD. I have an idea of what I want to do. I always wanted to keep studying. If there's an option that I could just keep studying and not do work or anything of that sort, I'd just pick that other one — I'll just keep studying.
But unfortunately, you need money and other things to live and sustain in this world. So I'm like, OK, I'll take a break from studies, and I will work for a while.
**CRAIG BOX: The road to success is littered with dreams of PhDs. I have a lot of friends who thought that that was the path they were going to take, and they've had a beautiful career and probably aren't going to go back to study. Did you use the [Matlab](https://en.wikipedia.org/wiki/MATLAB) software at all while you were going through your schooling?**
SAVITHA RAGHUNATHAN: No, unfortunately. That is a question that everyone asks. I have not used Matlab. I haven't used it even now. I don't use it for work. I didn't have any necessity for my school work. I didn't have anything to do with Matlab. I never analysed, or did data processing, or anything, with Matlab. So unfortunately, no.
Everyone asks me like, you're working at [MathWorks](https://en.wikipedia.org/wiki/MathWorks). Have you used Matlab? I'm like, no.
**CRAIG BOX: Fair enough. Nor have I. But it's been around since the late 1970s, so I imagine there are a lot of people who will have come across it at some point. Do you work with a lot of people who have been working on it that whole time?**
SAVITHA RAGHUNATHAN: Kind of. Not all the time, but I get to meet some folks who work on the product itself. Most of my interactions are with the infrastructure team and platform engineering teams at MathWorks. One other interesting fact is that when I joined the company — MathWorks has an extensive internal curriculum for training and learning, which I really love. They have an "Intro to Matlab" course, and that's on my bucket of things to do.
It was like 500 years ago. I added it, and I never got to it. I'm like, OK, maybe this year at least I want to get to it and I want to learn something new. My partner used Matlab extensively. He misses it right now at his current employer. And he's like, "you have the entire licence! You have access to the entire suite and you haven't used it?" I'm like, "no!"
**CRAIG BOX: Well, I have bad news for the idea of you doing a PhD, I'm sorry.**
SAVITHA RAGHUNATHAN: Another thing is that none of my family knew about the company MathWorks and Matlab. The only person who knew was my younger brother. He was so proud. He was like, "oh my God".
When he was 12 years old, he started getting involved in robotics and all that stuff. That's how he got introduced to Matlab. He goes absolutely bananas for the swag. So all the t-shirts, all the hoodies — any swag that I get from MathWorks goes to him, without saying.
Over the five, six years, the things that I've got — there was only one sweatshirt that I kept for myself. Everything else I've just given to him. And he cherishes it. He's the only one in my family who knew about Matlab and MathWorks.
Now, everyone knows, because I'm working there. They were initially like, I don't even know that company name. Is it like Amazon? I'm like, no, we make software that can send people to the moon. And we also make software that can do amazing robotic surgeries and even make a car drive on its own. That's something that I take immense pride in.
I know I don't directly work on the product, but I'm enabling the people who are creating the product. I'm really, really proud of that.
**CRAIG BOX: I think Jeff Bezos is working on at least two out of three of those disciplines that you mentioned before, so it's maybe a little bit like Amazon. One thing I've always thought about Matlab is that, because it's called Matlab, it solves that whole problem where [Americans call it math, and the rest of the world call it maths](https://www.grammar.com/math_vs._maths). Why do Americans think there's only one math?**
SAVITHA RAGHUNATHAN: Definitely. I had trouble — growing up in India, it's always British English. And I had so much trouble when I moved here. So many things changed.
One of the things is maths. I always got used to writing maths, physics, and everything.
**CRAIG BOX: They don't call it "physic" in the US, do they?**
SAVITHA RAGHUNATHAN: No, no, they don't. Luckily, they don't. That still stays "physics". But math — I had trouble. It's maths. Even when you do the full abbreviations like mathematics and you are still calling it math, I'm like, mm.
**CRAIG BOX: They can do the computer science abbreviation thing and call it math-7-S or whatever the number of letters is.**
SAVITHA RAGHUNATHAN: Just like Kubernetes. K-8-s.
**CRAIG BOX: Your path to Kubernetes is through MathWorks. They started out as a company making software which was distributed in a physical sense — boxed copies, if you will. I understand now there is a cloud version. Can I assume that that is where the two worlds intersect?**
SAVITHA RAGHUNATHAN: Kind of. I have interaction with the team that supports Matlab on the cloud, but I don't get to work with them on a day-to-day basis. They use Docker containers, and they are building the platform using Kubernetes. So yeah, a little bit of that.
**CRAIG BOX: So what exactly is the platform that you are engineering day to day?**
SAVITHA RAGHUNATHAN: Providing Kubernetes as a platform, obviously — that goes without saying — to some of the internal development teams. In the future we might expand it to more teams within the company. That is a focus area right now, so that's what we are doing. In the process, we might even get to work with the people who are deploying Matlab on the cloud, which is exciting.
**CRAIG BOX: Now, your path to contribution to Kubernetes, you've said before, was through [fixing a 404 error on the Kubernetes.io website](https://github.com/kubernetes/website/pull/15588). Do you remember what the page was?**
SAVITHA RAGHUNATHAN: I do. I was going to something for work, and I came across this changelog. In Kubernetes there's a nice page — once you got to the release page, there would be a long list of changelogs.
One of the things that I fixed was, the person who worked on the feature had changed their GitHub handle, and that wasn't reflected on this page. So that was my first. I got curious and clicked on the links. One of the links was the handle, and that went to a 404. And I was like "Yeah, I'll just fix that. They have done all the hard work. They can get the credit that's due".
It was easy. It wasn't overwhelming for me to pick it up as my first issue. Before that I logged on around Kubernetes for about six to eight months without doing anything because it was just a lot.
**CRAIG BOX: One of the other things that you said about your initial contribution is that you had to learn how to use Git. As a very powerful tool, I find Git is a high barrier to entry for even contributing code to a project. When you want to contribute a blog post or documentation or a fix like you did before, I find it almost impossible to think how a new user would come along and do that. What was your process? Do you think that there's anything we can do to make that barrier lower for new contributors?**
SAVITHA RAGHUNATHAN: Of course. There are more and more tutorials available these days. There is a new contributor workshop. They actually have a [GitHub workflow section](https://www.kubernetes.dev/docs/guide/github-workflow/), [how to do a pull request](https://www.kubernetes.dev/docs/guide/pull-requests/) and stuff like that. I know a couple of folks from SIG Docs that are working on which Git commands that you need, or how to get to writing something small and getting it committed. But more tutorials or more links to intro to Git would definitely help.
The thing is also, someone like a documentation writer — they don't actually want to know the entirety of Git. Honestly, it's an ocean. I don't know how to do it. Most of the time, I still ask for help even though I work with Git on a day to day basis. There are several articles and a lot of help is available already within the community. Maybe we could just add a couple more to [kubernetes.dev](https://kubernetes.dev/). That is an amazing site for all the new contributors and existing contributors who want to build code, who want to write documentation.
We could just add a tutorial there like, "hey, don't know Git, you are new to Git? You just need to know these main things".
**CRAIG BOX: I find it a shame, to be honest, that people need to use Git for that, by comparison to Wikipedia where you can come along, and even though it might be written in Markdown or something like it, it seems like the barrier is a lot lower. Similar to you, I always have to look up anything more complicated than the five or six Git commands that I use on a day to day basis. Even to do simple things, I basically just go and follow a recipe which I find on the internet.**
SAVITHA RAGHUNATHAN: This is how I got introduced to one of the amazing mentors in Kubernetes. Everyone knows him by his handle, Dims. It was my second PR to the Kubernetes website, and I made a mistake. I destroyed the Git history. I could not push my reviews and comments — I addressed them. I couldn't push them back.
My immediate thought was to delete it and recreate, do another pull request. But then I was like, "what happens to others who have already put effort into reviewing them?" I asked for help, and Dims was there.
I would say I just got lucky he was there. And he was like, "OK, let me walk you through". We did troubleshooting through Slack messages. I copied and pasted all the errors. Every single command that he said, I copied and pasted. And then he was like, "OK, run this one. Try this one. And do this one".
Finally, I got it fixed. So you know what I did? I went and I stored the command history somewhere local for the next time when I run into this problem. Luckily, I haven't. But I find the contributors so helpful. They are busy. They have a lot of things to do, but they take moments to stop and help someone who's new.
That is also another part of the reason why I stay — I want to contribute more. It's mainly the community. It's the Kubernetes community. I know you asked me about Git, and I just took the conversation to the Kubernetes community. That's how my brain works.
**CRAIG BOX: A lot of people in the community do that and think that's fantastic, obviously, people like Dims who are just floating around on Slack and seem to have endless time. I don't know how they do it.**
SAVITHA RAGHUNATHAN: I really want to know the secret for endless time. If I only had 48 hours in a day. I would sleep for 16 hours, and I would use the rest of the time for doing the things that I want.
**CRAIG BOX: If I had a chance to sleep up to 48 hours a day, I think it'd be a lot more than 16.**
**Now, one of the areas that you've been contributing to Kubernetes is in the release team. In 1.18, you were a shadow for the docs role. You led that role in 1.19. And you were a release lead shadow for versions 1,20 and 1.21 before finally leading this release, 1.22, which we will talk about soon.**
**How did you get involved? And how did you decide which roles to take as you went through that process?**
SAVITHA RAGHUNATHAN: That is a topic I love to talk about. This was fresh when I started learning about Kubernetes and using Kubernetes at work. And I got so much help from the community, I got interested in contributing back.
At the first KubeCon that I attended in 2018, in Seattle, they had a speed mentoring session. Now they call it "pod mentoring". I went to the session, and said, "hey, I want to contribute. I don't know where to start". And I got a lot of information on how to get started.
One of the places was SIG Release and the release team. I came back and diligently attended all the SIG Release meetings for four to six months. And in between, I applied to the Kubernetes release team — 1.14 and 1.15. I didn't get through. So I took a little bit of a break, and I focused on doing some documentation work. Then I applied for 1.18.
Since I was already working on some kinds of — not like full fledged "documentation" documentation, I still don't write. I eventually want to write something really nice and full fledged documentation like other awesome folks.
**CRAIG BOX: You'll need a lot more than 48 hours in your day to do that.**
SAVITHA RAGHUNATHAN: *laughing* That's how I applied for the docs role, because I know a little bit about the website. I've done a few pull requests and commits. That's how I got started. I applied for that one role, and I got selected for the 1.18 team. That's how my journey just took off.
And the next release, I was leading the documentation team. And as everyone knows, the pandemic hit. It was one of the longest releases. I could lean back on the community. I would just wait for the release team meetings.
It was my way of coping with the pandemic. It took my mind off. It was actually more than a release team, they were people. They were all people first, and we took care of each other. So it felt good.
And then, I became a release lead shadow for 1.20 and 1.21 because I wanted to know more. I wanted to learn more. I wasn't ready. I still don't feel ready, but I have led 1.22. So if I could do it, anyone could do it.
**CRAIG BOX: How much of this work is day job?**
SAVITHA RAGHUNATHAN: I am lucky to be blessed with an awesome team. I do most of my work after work, but there have been times where I have to take meetings and attend to immediate urgent stuff. During the time of exception requests and stuff like that, I take a little bit of time from my work.
My team has been wonderful: they support me in all possible ways, and the management as well. Other than the meetings, I don't do much of the work during the day job. It just takes my focus and attention away too much, and I end up having to spend a lot of time sitting in front of the computer, which I don't like.
Before the pandemic I had a good work life balance. I'd just go to work at 7:00, 7:30, and I'd be back by 4 o'clock. I never touched my laptop ever again. I left all work behind when I came home. So right now, I'm still learning how to get through.
I try to limit the amount of open source work that I do during work time. The release lead shadow and the release lead job — they require a lot of time, effort. So on average, I'd be spending two to three hours post work time on the release activities.
**CRAIG BOX: Before the pandemic, everyone was worried that if we let people work from home, they wouldn't work enough. I think the opposite has actually happened, is that now we're worried that if we let people work from home, they will just get on the computer in the morning and you'll have to pry it out of their hands at midnight.**
SAVITHA RAGHUNATHAN: Yeah, I think the productivity has increased at least twofold, I would say, for everyone, once they started working from home.
**CRAIG BOX: But at the expense of work-life balance, though, because as you say, when you're sitting in the same chair in front of, perhaps, the same computer doing your MathWorks work and then your open source work, they kind of can blur into one perhaps?**
SAVITHA RAGHUNATHAN: That is a challenge. I face it every day. But so many others are also facing it. I implemented a few little tricks to help me. When I used to come back home from work, the first thing I would do is remove my watch. That was an indication that OK, I'm done.
That's the thing that I still do. I just remove my watch, and I just keep it right where my workstation is. And I just close the door so that I never look back. Even going past the room, I don't get a glimpse of my work office. I start implementing tiny little things like that to avoid burnout.
I think I'm still facing a little bit of burnout. I don't know if I have fully recovered from it. I constantly feel like I need a vacation. And I could just take a vacation for like a month or two. If it's possible, I will just do it.
**CRAIG BOX: I do hope that travel opens up for everyone as an opportunity because I know that, for a lot of people, it's not so much they've been working from home but they've been living at work. The idea of taking vacation effectively means, well, I've been stuck in the same place, if I've been under a lockdown. It's hard to justify that. It will be good as things improve worldwide for us to be able to start focusing more on mental health and perhaps getting away from the "everything room," as I sometimes call it.**
SAVITHA RAGHUNATHAN: I'm totally looking forward to it. I hope that travel opens up and I could go home and I could meet my siblings and my aunt and my parents.
**CRAIG BOX: Catch a cricket match?**
SAVITHA RAGHUNATHAN: Yeah. Probably yes, if I have company and if there is anything interesting happening around the time. I don't mind going back to the Chepauk Stadium and catching a match or two.
**CRAIG BOX: Let's turn now to the recently released [Kubernetes 1.22](https://kubernetes.io/blog/2021/08/04/kubernetes-1-22-release-announcement/). Congratulations on the launch.**
SAVITHA RAGHUNATHAN: Thank you.
**CRAIG BOX: Each launch comes with a theme and a mascot or a logo. What is the theme for this release?**
SAVITHA RAGHUNATHAN: The theme for the release is reaching new peaks. I am fascinated with a lot of space travel and chasing stars, the Milky Way. The best place to do that is over the top of a mountain. So that is the release logo, basically. It's a mountain — Mount Rainier. On top of that, there is a Kubernetes flag, and it's overlooking the Milky Way.
It's also symbolic that with every release, that we are achieving something new, bigger, and better, and we are making the release awesome. So I just wanted to incorporate that into the team as to say, we are achieving new things with every release. That's the "reaching new peaks" theme.
**CRAIG BOX: The last couple of releases have both been incrementally larger — as a result, perhaps, of the fact there are now only three releases per year rather than four. There were also changes to the process, where the work has been driven a lot more by the SIGs than by the release team having to go and ask the SIGs what was going on. What can you say about the size and scope of the 1.22 release?**
SAVITHA RAGHUNATHAN: The 1.22 release is the largest release to date. We have 56 enhancements if I'm not wrong, and we have a good amount of features that's graduated as stable. You can now say that Kubernetes as a project has become more mature because you see new features coming in. At the same time, you see the features that weren't used getting deprecated — we have like three deprecations in this release.
Aside from that fact, we also have a big team that's supporting one of the longest releases. This is the first official release cycle after the cadence KEP got approved. Officially, we are at four months, even though 1.19 was six months, and 1.21 was like 3 and 1/2 months, I think, this is the first one after the official KEP approval.
**CRAIG BOX: What changes did you make to the process knowing that you had that extra month?**
SAVITHA RAGHUNATHAN: One of the things the community had asked for is more time for development. We tried to incorporate that in the release schedule. We had about six weeks between the enhancements freeze and the code freeze. That's one.
It might not be visible to everyone, but one of the things that I wanted to make sure of was the health of the team — since it was a long, long release, we had time to plan out, and not have everyone work during the weekends or during their evenings or time off. That actually helped everyone keep their sanity, and also in making good progress and delivering good results at the end of the release. That's one of the process improvements that I'd call out.
We got better by making a post during the exception request process. Everyone works around the world. People from the UK start a little earlier than the people in the US East Coast. The West Coast starts three hours later than the East Coast. We used to make a post every Friday evening saying "hey, we actually received this many requests. We have addressed a number of them. We are waiting on a couple, or whatever. All the release team members are done for the day. We will see you around on Monday. Have a good weekend." Something like that.
We set the expectations from the community as well. We understand things are really important and urgent, but we are done. This gave everyone their time back. They don't have to worry over the weekend thinking like, hey, what's happening? What's happening in the release? They could spend time with their family, or they could do whatever they want to do, like go on a hike, or just sit and watch TV.
There have been weekends that I just did that. I just binge-watched a series. That's what I did.
**CRAIG BOX: Any recommendations?**
SAVITHA RAGHUNATHAN: I'm a big fan of Marvel, so I have watched the new [Loki](https://en.wikipedia.org/wiki/Loki_(TV_series)), which I really love. Loki is one of my favourite characters in Marvel. And I also liked [WandaVision](https://en.wikipedia.org/wiki/WandaVision). That was good, too.
**CRAIG BOX: I've not seen Loki yet, but I've heard it described as the best series of Doctor Who in the last few years.**
SAVITHA RAGHUNATHAN: Really?
**CRAIG BOX: There must be an element of time-travelling in there if that's how people are describing it.**
SAVITHA RAGHUNATHAN: You should really go and watch it whenever you have time. It's really amazing. I might go back and watch it again because I might have missed bits and pieces. That always happens in Marvel movies and the episodes; you need to watch them a couple of times to catch, "oh, this is how they relate".
**CRAIG BOX: Yes, the mark of good media that you want to immediately go back and watch it again once you've seen it.**
**Let's look now at some of the new features in Kubernetes 1.22. A couple of things that have graduated to general availability — server-side apply, external credential providers, a couple of new security features — the replacement for pod security policy has been announced, and seccomp is now available by default.**
**Do you have any favourite features in 1.22 that you'd like to discuss?**
SAVITHA RAGHUNATHAN: I have a lot of them. All my favourite features are related to security. OK, one of them is not security, but a major theme of my favourite KEPs is security. I'll start with the [default seccomp](https://github.com/kubernetes/enhancements/issues/2413). I think it will help make clusters secure by default, and may assist in preventing more vulnerabilities, which means less headaches for the cluster administrators.
This is close to my heart because the base of the MathWorks platform is provisioning Kubernetes clusters. Knowing that they are secure by default will definitely provide me with some good sleep. And also, I'm paranoid about security most of the time. I'm super interested in making everything secure. It might get in the way of making the users of the platform angry because it's not usable in any way.
My next one is [rootless Kubelet](https://github.com/kubernetes/enhancements/issues/2033). That feature's going to enable the cluster admin, the platform developers to deploy Kubernetes components to run in a user namespace. And I think that is also a great addition.
Like you mention, the most awaited drop in for the PSP replacement is here. It's [pod admission control](https://github.com/kubernetes/enhancements/issues/2579). It lets cluster admins apply the pod security standards. And I think it's just not related to the cluster admins. I might have to go back and check on that. Anyone can probably use it — the developers and the admins alike.
It also supports various modes, which is most welcome. There are times where you don't want to just cut the users off because they are trying to do something which is not securely correct. You just want to warn them, hey, this is what you are doing. This might just cause a security issue later, so you might want to correct it. But you just don't want to cut them off from using the platform, or them trying to attempt to do something — deploy their workload and get their day-to-day job done. That is something that I really like, that it also supports a warning mechanism.
Another one which is not security is [node swap support](https://github.com/kubernetes/enhancements/issues/2400). Kubernetes didn't have support for swap before, but it is taken into consideration now. This is an alpha feature. With this, you can take advantage of the swap, which is provisioned on the Linux VMs.
Some of the workloads — when they are deployed, they might need a lot of swap for the start-up — example, like Node and Java applications, which I just took out of their KEP user stories. So if anyone's interested, they can go and look in the KEP. That's useful. And it also increases the node stability and whatnot. So I think it's going to be beneficial for a lot of folks.
We know how Java and containers work. I think it has gotten better, but five years ago, it was so hard to get a Java application to fit in a small container. It always needed a lot of memory, swap, and everything to start up and run. I think this will help the users and help the admins and keep the cost low, and it will tie into so many other things as well. I'm excited about that feature.
Another feature that I want to just call out — I don't use Windows that much, but I just want to give a shout out to the folks who are doing an amazing job bringing all the Kubernetes features to Windows as well, to give a seamless experience.
One of the things is [Windows privileged containers](https://github.com/kubernetes/enhancements/issues/1981). I think it went alpha this release. And that is a wonderful addition, if you ask me. It can take advantage of whatever that's happening on the Linux side. And they can also port it over and see, OK, I can now run Windows containers in a privileged mode.
So whatever they are trying to achieve, they can do it. So that's a noteworthy mention. I need to give a shout out for the folks who work and make things happen in the Windows ecosystem as well.
**CRAIG BOX: One of the things that's great about the release process is the continuity between groups and teams. There's always an emeritus advisor who was a lead from a previous release. One thing that I always ask when I do these interviews is, what is the advice that you give to the next person? When [we talked to Nabarun for the 1.21 interview](https://kubernetespodcast.com/episode/146-kubernetes-1.21/), he said that his advice to you would be "do, delegate, and defer". Figure out what you can do, figure out what you can ask other people to do, and figure out what doesn't need to be done. Were you able to take that advice on board?**
SAVITHA RAGHUNATHAN: Yeah, you won't believe it. [I have it right here stuck to my monitor.](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/3)
**CRAIG BOX: Next to your Git cheat sheet?**
SAVITHA RAGHUNATHAN: *laughs* Absolutely. I just have it stuck there. I just took a look at it.
**CRAIG BOX: Someone that you will have been able to delegate and defer to is Rey Lejano from Rancher Labs and SUSE, who is the release lead to be for 1.23.**
SAVITHA RAGHUNATHAN: I want to tell Rey to beware of the team's mental health. Schedule in such a way that it avoids burnout. Check in, and make sure that everyone is doing good. If they need some kind of help, create a safe space where they can actually ask for help, if they want to step back, if they need someone to cover.
I think that is most important. The releases are successful based on the thousands and thousands of contributors. But when it comes to a release team, you need to have a healthy team where people feel they are in a good place and they just want to make good contributions, which means they want to be heard. That's one thing that I want to tell Rey.
Also collaborate and learn from each other. I constantly learn. I think the team was 39 folks, including me. Every day I learned something or the other, even starting from how to interact.
Sometimes I have learned more leadership skills from my release lead shadows. They are awesome, and they are mature. I constantly learn from them, and I admire them a lot.
It also helps to have good, strong individuals in the team who can step up and help when needed. For example, unfortunately, we lost one of our teammates after the start of the release cycle. That was tragic. His name was [Peeyush Gupta](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md). He was an awesome and wonderful human — very warm.
I didn't get more of a chance to interact with him. I had exchanged a few Slack messages, but I got his warm personality. I just want to take a couple of seconds to remember him. He was awesome.
After we lost him, we had this strong person from the team step up and lead the communications, who had never been a part of the release team before at all. He was a shadow for the first time. His name is Jesse Butler. So he stepped up, and he just took it away. He ran the comms show for 1.22.
That's what the community is about. You take care of team members, and the team will take care of you. So that's one other thing that I want to let Rey know, and maybe whoever — I think it's applicable overall.
**CRAIG BOX: There's a link to a [family education fund for Peeyush Gupta](https://milaap.org/fundraisers/support-peeyush-gupta-family-education), which you can find in the show notes.**
**Five releases in a row now you've been a member of the release team. Will you be putting your feet up now for 1.23?**
SAVITHA RAGHUNATHAN: I am going to take a break for a while. In the future, I want to be contributing, if not the release team, the SIG Release and the release management effort. But right now, I have been there for five releases. And I feel like, OK, I just need a little bit of fresh air.
And also the pandemic and the burnout has caught up, so I'm going to take a break from certain contributions. You will see me in the future. I will be around, but I might not be actively participating in the release team activities. I will be around the community. Anyone can reach out to me. They all know my Slack, so they can just reach out to me via Slack or Twitter.
**CRAIG BOX: Yes, your Twitter handle is CoffeeArtGirl. Does that mean that you'll be spending some time working on your lattes?**
SAVITHA RAGHUNATHAN: I am very bad at making lattes. The coffee art means that I used to [make art with coffee](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/1). You get instant coffee powder and just mix it with water. You get the colours, very beautiful brown colours. I used to make art using that.
And I love coffee. So I just combined all the words together. And I had to come up with it in a span of one hour or so because I was joining this 'meet our contributors' panel. And Paris asked me, "do you have a Twitter handle?" I was planning to create one, but I didn't have the time.
I'm like, well, let me just think what I could just come up with real quick. So I just came up with that. So that's the story behind my Twitter handle. Everyone's interested in it. You are not the first person you have asked me or mentioned about it. So many others are like, why coffee art?
**CRAIG BOX: And you are also interested in art with perhaps other materials?**
SAVITHA RAGHUNATHAN: Yes. My interests keep changing. I used to do pebble art. It's just collecting pebbles from wherever I go, and I used to paint on them. I used to use watercolour, but I want to come back to watercolour sometime.
My recent interests are coloured pencils, which came back. When I was very young, I used to do a lot of coloured pencils. And then I switched to watercolours and oil painting. So I just go around in circles.
One of the hobbies that I picked up during a pandemic is crochet. I made a scarf for Mother's Day. My mum and my dad were here last year. They got stuck because of the pandemic, and they couldn't go back home. So they stayed with me for 10 months. That is the jackpot that I had, that I got to spend so much time with my parents after I moved to the US.
**CRAIG BOX: And they got rewarded with a scarf.**
SAVITHA RAGHUNATHAN: Yeah.
**CRAIG BOX: One to share between them.**
SAVITHA RAGHUNATHAN: I started making a blanket for my dad. And it became so heavy, I might have to just pick up some lighter yarn. I still don't know the differences between different kinds of yarns, but I'm getting better.
I started out because I wanted to make these little toys. They call them [amigurumi](https://en.wikipedia.org/wiki/Amigurumi) in the crochet world. I wanted to make them. That's why I started out. I'm trying. I made [a little cat](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/2) which doesn't look like a cat, but it is a cat. I have to tell everyone that it's a cat so that they don't mock me later, but.
**CRAIG BOX: It's an artistic interpretation of a cat.**
SAVITHA RAGHUNATHAN: It definitely is!
---
_[Savitha Raghunathan](https://twitter.com/coffeeartgirl), now a Senior Software Engineer at Red Hat, served as the Kubernetes 1.22 release team lead._
_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._

17
content/en/docs/concepts/architecture/nodes.md
View File

@ -402,7 +402,7 @@ Graceful node shutdown is controlled with the `GracefulNodeShutdown`
enabled by default in 1.21.
Note that by default, both configuration options described below,
`ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero,
`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero,
thus not activating Graceful node shutdown functionality.
To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
@ -412,13 +412,13 @@ During a graceful shutdown, kubelet terminates pods in two phases:
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
* `ShutdownGracePeriod`:
* `shutdownGracePeriod`:
* Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
* `ShutdownGracePeriodCriticalPods`:
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `ShutdownGracePeriod`.
* `shutdownGracePeriodCriticalPods`:
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `shutdownGracePeriod`.
For example, if `ShutdownGracePeriod=30s`, and
`ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
For example, if `shutdownGracePeriod=30s`, and
`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved
for gracefully terminating normal pods, and the last 10 seconds would be
reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
@ -535,6 +535,11 @@ the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
must be set to false.
{{< warning >}}
When the memory swap feature is turned on, Kubernetes data such as the content
of Secret objects that were written to tmpfs now could be swapped to disk.
{{< /warning >}}
A user can also optionally configure `memorySwap.swapBehavior` in order to
specify how a node will use swap memory. For example,

5
content/en/docs/concepts/cluster-administration/addons.md
View File

@ -45,6 +45,11 @@ This page lists some of the available add-ons and links to their respective inst
## Infrastructure
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
* The
[node problem detector](https://github.com/kubernetes/node-problem-detector)
runs on Linux nodes and reports system issues as either
[Events](/docs/reference/kubernetes-api/cluster-resources/event-v1/) or
[Node conditions](/docs/concepts/architecture/nodes/#condition).
## Legacy Add-ons

6
content/en/docs/concepts/cluster-administration/flow-control.md
View File

@ -26,6 +26,10 @@ fair queuing technique so that, for example, a poorly-behaved
{{< glossary_tooltip text="controller" term_id="controller" >}} need not
starve others (even at the same priority level).
This feature is designed to work well with standard controllers, which
use informers and react to failures of API requests with exponential
back-off, and other clients that also work this way.
{{< caution >}}
Requests classified as "long-running" — primarily watches — are not
subject to the API Priority and Fairness filter. This is also true for
@ -102,6 +106,8 @@ name of the matching FlowSchema plus a _flow distinguisher_ — which
is either the requesting user, the target resource's namespace, or nothing — and the
system attempts to give approximately equal weight to requests in different
flows of the same priority level.
To enable distinct handling of distinct instances, controllers that have
many instances should authenticate with distinct usernames
After classifying a request into a flow, the API Priority and Fairness
feature then may assign the request to a queue. This assignment uses

43
content/en/docs/concepts/cluster-administration/networking.md
View File

@ -169,49 +169,6 @@ With this toolset DANM is able to provide multiple separated network interfaces,
network that satisfies the Kubernetes requirements. Many
people have reported success with Flannel and Kubernetes.
### Google Compute Engine (GCE)
For the Google Compute Engine cluster configuration scripts, [advanced
routing](https://cloud.google.com/vpc/docs/routes) is used to
assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for that
subnet will be routed directly to the VM by the GCE network fabric. This is in
addition to the "main" IP address assigned to the VM, which is NAT'ed for
outbound internet access. A linux bridge (called `cbr0`) is configured to exist
on that subnet, and is passed to docker's `--bridge` flag.
Docker is started with:
```shell
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
```
This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
flag) according to the `Node`'s `.spec.podCIDR`.
Docker will now allocate IPs from the `cbr-cidr` block. Containers can reach
each other and `Nodes` over the `cbr0` bridge. Those IPs are all routable
within the GCE project network.
GCE itself does not know anything about these IPs, though, so it will not NAT
them for outbound internet traffic. To achieve that an iptables rule is used
to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
itself) traffic that is bound for IPs outside the GCE project network
(10.0.0.0/8).
```shell
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
```
Lastly IP forwarding is enabled in the kernel (so the kernel will process
packets for bridged containers):
```shell
sysctl net.ipv4.ip_forward=1
```
The result of all this is that all `Pods` can reach each other and can egress
traffic to the internet.
### Jaguar
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.

4
content/en/docs/concepts/configuration/manage-resources-containers.md
View File

@ -116,11 +116,11 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
Limits and requests for `memory` are measured in bytes. You can express memory as
a plain integer or as a fixed-point number using one of these suffixes:
E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
E, P, T, G, M, k, m (millis). You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following represent roughly the same value:
```shell
128974848, 129e6, 129M, 123Mi
128974848, 129e6, 129M, 128974848000m, 123Mi
```
Here's an example.

9
content/en/docs/concepts/services-networking/ingress-controllers.md
View File

@ -57,12 +57,11 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
## Using multiple Ingress controllers
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
to indicate which ingress controller should be used if more than one exists within your cluster.
You may deploy any number of ingress controllers using [ingress class](/docs/concepts/services-networking/ingress/#ingress-class)
within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation).
If you do not define a class, your cloud provider may use a default ingress controller.
If you do not specify an IngressClass for an Ingress, and your cluster has exactly one IngressClass marked as default, then Kubernetes [applies](/docs/concepts/services-networking/ingress/#default-ingress-class) the cluster's default IngressClass to the Ingress.
You mark an IngressClass as default by setting the [`ingressclass.kubernetes.io/is-default-class` annotation](/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) on that IngressClass, with the string value `"true"`.
Ideally, all ingress controllers should fulfill this specification, but the various ingress
controllers operate slightly differently.

2
content/en/docs/concepts/storage/ephemeral-volumes.md
View File

@ -7,7 +7,7 @@ reviewers:
- pohly
title: Ephemeral Volumes
content_type: concept
weight: 50
weight: 30
---
<!-- overview -->

3
content/en/docs/concepts/storage/persistent-volumes.md
View File

@ -10,14 +10,13 @@ feature:
title: Storage orchestration
description: >
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
content_type: concept
weight: 20
---
<!-- overview -->
This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
This document describes _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
<!-- body -->

4
content/en/docs/concepts/storage/projected-volumes.md
View File

@ -1,16 +1,16 @@
---
reviewers:
- sftim
- marosset
- jsturtevant
- zshihang
title: Projected Volumes
content_type: concept
weight: 21 # just after persistent volumes
---
<!-- overview -->
This document describes the current state of _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
<!-- body -->

3
content/en/docs/concepts/storage/storage-capacity.md
View File

@ -7,7 +7,7 @@ reviewers:
- pohly
title: Storage Capacity
content_type: concept
weight: 45
weight: 70
---
<!-- overview -->
@ -16,7 +16,6 @@ Storage capacity is limited and may vary depending on the node on
which a pod runs: network-attached storage might not be accessible by
all nodes, or storage is local to a node to begin with.
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
This page describes how Kubernetes keeps track of storage capacity and

2
content/en/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -6,7 +6,7 @@ reviewers:
- msau42
title: CSI Volume Cloning
content_type: concept
weight: 30
weight: 60
---
<!-- overview -->

2
content/en/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -8,7 +8,7 @@ reviewers:
- yuxiangqian
title: Volume Snapshot Classes
content_type: concept
weight: 30
weight: 41 # just after volume snapshots
---
<!-- overview -->

2
content/en/docs/concepts/storage/volume-snapshots.md
View File

@ -8,7 +8,7 @@ reviewers:
- yuxiangqian
title: Volume Snapshots
content_type: concept
weight: 20
weight: 40
---
<!-- overview -->

31
content/en/docs/concepts/workloads/controllers/deployment.md
View File

@ -32,7 +32,7 @@ The following are typical use cases for Deployments:
* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
* [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
* [Pause the rollout of a Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
@ -697,9 +697,12 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## Pausing and Resuming a Deployment
## Pausing and Resuming a rollout of a Deployment {#pausing-and-resuming-a-deployment}
You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
When you update a Deployment, or plan to, you can pause rollouts
for that Deployment before you trigger one or more updates. When
you're ready to apply those changes, you resume rollouts for the
Deployment. This approach allows you to
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
* For example, with a Deployment that was created:
@ -775,10 +778,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
deployment.apps/nginx-deployment resource requirements updated
```
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
the Deployment will not have any effect as long as the Deployment is paused.
The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to
the Deployment will not have any effect as long as the Deployment rollout is paused.
* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
* Eventually, resume the Deployment rollout and observe a new ReplicaSet coming up with all the new updates:
```shell
kubectl rollout resume deployment/nginx-deployment
```
@ -912,8 +915,8 @@ example, rollback the Deployment to its previous version.
{{< /note >}}
{{< note >}}
If you pause a Deployment, Kubernetes does not check progress against your specified deadline.
You can safely pause a Deployment in the middle of a rollout and resume without triggering
If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
the condition for exceeding the deadline.
{{< /note >}}
@ -1065,6 +1068,18 @@ allowed, which is the default if not specified.
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
Should you manually scale a Deployment, example via `kubectl scale deployment
deployment --replicas=X`, and then you update that Deployment based on a manifest
(for example: by running `kubectl apply -f deployment.yaml`),
then applying that manifest overwrites the manual scaling that you previously did.
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
Instead, allow the Kubernetes
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} to manage the
`.spec.replicas` field automatically.
### Selector
`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)

16
content/en/docs/concepts/workloads/controllers/statefulset.md
View File

@ -379,6 +379,22 @@ which will verify owner references before terminating Pods. If that is not possi
operator should verify the owner references on PVCs to ensure the expected objects are
deleted when Pods are force-deleted.
### Replicas
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
Should you manually scale a deployment, example via `kubectl scale
statefulset statefulset --replicas=X`, and then you update that StatefulSet
based on a manifest (for example: by running `kubectl apply -f
statefulset.yaml`), then applying that manifest overwrites the manual scaling
that you previously did.
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
(or any similar API for horizontal scaling) is managing scaling for a
Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
{{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
the `.spec.replicas` field automatically.
## {{% heading "whatsnext" %}}
* Learn about [Pods](/docs/concepts/workloads/pods).

2
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -159,7 +159,7 @@ through which the Pod has or has not passed:
* `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.
have completed successfully.
* `Ready`: the Pod is able to serve requests and should be added to the load
balancing pools of all matching Services.

14
content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -85,7 +85,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
It must be greater than zero. Its semantics differs according to the value of `whenUnsatisfiable`:
- when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
permitted difference between the number of matching pods in the target
topology and the global minimum
topology and the global minimum
(the minimum number of pods that match the label selector in a topology domain. For example, if you have 3 zones with 0, 2 and 3 matching pods respectively, The global minimum is 0).
- when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
precedence to topologies that would help reduce the skew.
@ -234,6 +234,8 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
### Example: TopologySpreadConstraints with NodeAffinity
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
{{<mermaid>}}
@ -349,12 +351,14 @@ Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
is disabled.
{{< note >}}
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints. This might result
in a different default behavior compared to the legacy `SelectorSpread` plugin when
using the default topology constraints.
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
`topology.kubernetes.io/zone` labels set, define your own constraints
instead of using the Kubernetes defaults.
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints.
{{< /note >}}
If you don't want to use the default Pod spreading constraints for your cluster,
@ -392,7 +396,7 @@ for more details.
## Known Limitations
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)

10
content/en/docs/contribute/advanced.md
View File

@ -27,7 +27,7 @@ the documentation, the website style, the processes for reviewing and merging
pull requests, or other aspects of the documentation. For maximum transparency,
these types of proposals need to be discussed in a SIG Docs meeting or on the
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
In addition, it can really help to have some context about the way things
In addition, it can help to have some context about the way things
currently work and why past decisions have been made before proposing sweeping
changes. The quickest way to get answers to questions about how the documentation
currently works is to ask in the `#sig-docs` Slack channel on
@ -54,7 +54,7 @@ refer to
The SIG Docs representative for a given release coordinates the following tasks:
- Monitor the feature-tracking spreadsheet for new or changed features with an
impact on documentation. If documentation for a given feature won't be ready
impact on documentation. If the documentation for a given feature won't be ready
for the release, the feature may not be allowed to go into the release.
- Attend sig-release meetings regularly and give updates on the status of the
docs for the release.
@ -82,12 +82,12 @@ few PR submissions.
Responsibilities for New Contributor Ambassadors include:
- Monitoring the [#sig-docs Slack channel](https://kubernetes.slack.com) for questions from new contributors.
- Working with PR wranglers to identify good first issues for new contributors.
- Working with PR wranglers to identify [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue) for new contributors.
- Mentoring new contributors through their first few PRs to the docs repo.
- Helping new contributors create the more complex PRs they need to become Kubernetes members.
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
Current New Contributor Ambassadors are announced at each SIG-Docs meeting and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
## Sponsor a new contributor
@ -122,7 +122,7 @@ Approvers must meet the following requirements to be a co-chair:
- 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),
[teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), the
[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).

1
content/en/docs/contribute/new-content/blogs-case-studies.md
View File

@ -38,6 +38,7 @@ Anyone can write a blog post and submit it for review.
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
- Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev)
- Blog posts should be original content
- The official blog is not for repurposing existing content from a third party as new content.
- The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.

8
content/en/docs/contribute/participate/pr-wranglers.md
View File

@ -29,7 +29,13 @@ Each day in a week-long shift as PR Wrangler:
- You can also tag a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) for a review by commenting `@kubernetes/<sig>-pr-reviews` on the PR.
- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
- PRs should have a `/lgtm` comment from another member before merging.
- Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
- Consider accepting technically accurate content that doesn't meet the
[style guidelines](/docs/contribute/style/style-guide/). As you approve the change,
open a new issue to address the style concern. You can usually write these style fix
issues as [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue).
- Using style fixups as good first issues is a good way to ensure a supply of easier tasks
to help onboard new contributors.
### Helpful GitHub queries for wranglers

2
content/en/docs/contribute/review/for-approvers.md
View File

@ -121,7 +121,7 @@ finds issues that might need triage.
`priority/important-longterm` | Do this within 6 months.
`priority/backlog` | Deferrable indefinitely. Do when resources are available.
`priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://kubernetes.dev/docs/guide/help-wanted/) for more information.
{{< /table >}}

4
content/en/docs/reference/access-authn-authz/admission-controllers.md
View File

@ -30,9 +30,9 @@ mutating and validating (respectively)
which are configured in the API.
Admission controllers may be "validating", "mutating", or both. Mutating
controllers may modify the objects they admit; validating controllers may not.
controllers may modify related objects to the requests they admit; validating controllers may not.
Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects.
The admission control process proceeds in two phases. In the first phase,
mutating admission controllers are run. In the second phase, validating

2
content/en/docs/reference/access-authn-authz/authentication.md
View File

@ -104,7 +104,7 @@ See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for ho
### Static Token File
The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be
changed without restarting API server.
changed without restarting the API server.
The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
followed by optional group names.

2
content/en/docs/reference/access-authn-authz/authorization.md
View File

@ -134,7 +134,7 @@ The output is similar to this:
no
```
Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
can list Pods in the Namespace `target`:
```bash

2
content/en/docs/reference/glossary/secret.md
View File

@ -15,4 +15,4 @@ tags:
<!--more-->
Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest. A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
Allows for more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and stored unencrypted by default, but can be configured to be [encrypted at rest](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.

3
content/en/docs/reference/kubectl/cheatsheet.md
View File

@ -311,8 +311,7 @@ kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
kubectl run nginx --image=nginx -n
mynamespace # Run pod nginx in a specific namespace
kubectl run nginx --image=nginx -n mynamespace # Start a single instance of nginx pod in the namespace of mynamespace
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
--dry-run=client -o yaml > pod.yaml

10
content/en/docs/reference/labels-annotations-taints.md
View File

@ -62,6 +62,16 @@ The Kubelet populates this label with the hostname. Note that the hostname can b
This label is also used as part of the topology hierarchy. See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information.
## kubernetes.io/change-cause {#change-cause}
Example: `kubernetes.io/change-cause=kubectl edit --record deployment foo`
Used on: All Objects
This annotation is a best guess at why something was changed.
It is populated when adding `--record` to a `kubectl` command that may change an object.
## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
Example: `controller.kubernetes.io/pod-deletion-cost=10`

110
content/en/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -214,115 +214,7 @@ In each case, the credentials of the pod are used to communicate securely with t
## Accessing services running on the cluster
The previous section was about connecting the Kubernetes API server. This section is about
connecting to other services running on Kubernetes cluster. In Kubernetes, the
[nodes](/docs/concepts/architecture/nodes/),
[pods](/docs/concepts/workloads/pods/) and
[services](/docs/concepts/services-networking/service/) all have
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
routable, so they will not be reachable from a machine outside the cluster,
such as your desktop machine.
### Ways to connect
You have several options for connecting to nodes, pods and services from outside the cluster:
- Access services through public IPs.
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
the cluster. See the [services](/docs/concepts/services-networking/service/) and
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
- Depending on your cluster environment, this may only expose the service to your corporate network,
or it may expose it to the internet. Think about whether the service being exposed is secure.
Does it do its own authentication?
- Place pods behind services. To access one specific pod from a set of replicas, such as for debugging,
place a unique label on the pod and create a new service which selects this label.
- In most cases, it should not be necessary for application developer to directly access
nodes via their nodeIPs.
- Access services, nodes, or pods using the Proxy Verb.
- Does apiserver authentication and authorization prior to accessing the remote service.
Use this if the services are not secure enough to expose to the internet, or to gain
access to ports on the node IP, or for debugging.
- Proxies may cause problems for some web applications.
- Only works for HTTP/HTTPS.
- Described [here](#manually-constructing-apiserver-proxy-urls).
- Access from a node or pod in the cluster.
- Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
Connect to other nodes, pods, and services from that shell.
- Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
access cluster services. This is a non-standard method, and will work on some clusters but
not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
### Discovering builtin services
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
with the `kubectl cluster-info` command:
```shell
kubectl cluster-info
```
The output is similar to this:
```
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
This shows the proxy-verb URL for accessing each service.
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at:
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.)
#### Manually constructing apiserver proxy URLs
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
The supported formats for the name segment of the URL are:
* `<service_name>` - proxies to the default or unnamed port using http
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
##### Examples
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
```json
{
"cluster_name" : "kubernetes_logging",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 5,
"active_shards" : 5,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5
}
```
### Using web browsers to access services running on the cluster
You may be able to put an apiserver proxy url into the address bar of a browser. However:
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
but your cluster may not be configured to accept basic auth.
- Some web apps may not work, particularly those with client side javascript that construct urls in a
way that is unaware of the proxy path prefix.
The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/)
## Requesting redirects

4
content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
View File

@ -70,7 +70,7 @@ The formatting can be controlled further by using the `range` operation to
iterate over elements individually.
```shell
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
```
@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The
following matches only Pods with labels matching `app=nginx`.
```shell
kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
```
## List Container images filtering by Pod namespace

13
content/en/docs/tasks/administer-cluster/access-cluster-services.md
View File

@ -86,7 +86,18 @@ See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/ac
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
By default, the API server proxies to your service using HTTP. To use HTTPS, prefix the service name with `https:`:
`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
The supported formats for the `<service_name>` segment of the URL are:
* `<service_name>` - proxies to the default or unnamed port using http
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
##### Examples

16
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -78,10 +78,6 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
@ -175,10 +171,6 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
@ -218,10 +210,6 @@ without compromising the minimum required capacity for running your workloads.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
@ -256,10 +244,6 @@ without compromising the minimum required capacity for running your workloads.
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version

9
content/en/docs/tasks/administer-cluster/nodelocaldns.md
View File

@ -91,4 +91,13 @@ If you are using the sample manifest from the previous point, this will require
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
## StubDomains and Upstream server Configuration
StubDomains and upstream servers specified in the `kube-dns` ConfigMap in the `kube-system` namespace
are automatically picked up by `node-local-dns` pods. The ConfigMap contents need to follow the format
shown in [the example](/docs/tasks/administer-cluster/dns-custom-nameservers/#example-1).
The `node-local-dns` ConfigMap can also be modified directly with the stubDomain configuration
in the Corefile format. Some cloud providers might not allow modifying `node-local-dns` ConfigMap directly.
In those cases, the `kube-dns` ConfigMap can be updated.

18
content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
View File

@ -11,7 +11,7 @@ min-kubernetes-server-version: v1.11
{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
{{< caution >}}
[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
The [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/281-dynamic-kubelet-configuration)
feature is deprecated and should not be used.
Please switch to alternative means distributing configuration to the Nodes of your cluster.
{{< /caution >}}
@ -37,13 +37,10 @@ fields is available in the inline
## {{% heading "prerequisites" %}}
You need to have a Kubernetes cluster.
You also need kubectl v1.11 or higher, configured to communicate with your cluster.
You also need `kubectl`, [installed](/docs/tasks/tools/#kubectl) and configured to communicate with your cluster.
Make sure that you are using a version of `kubectl` that is
[compatible](/releases/version-skew-policy/) with your cluster.
{{< version-check >}}
Your cluster API server version (eg v1.12) must be no more than one minor
version away from the version of kubectl that you are using. For example,
if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
or v1.17; other combinations
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
Some of the examples use the command line tool
[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
@ -383,9 +380,10 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
## {{% heading "whatsnext" %}}
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
- [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)
explains the supported way to configure a kubelet.
- See the reference documentation for Node, including the `configSource` field within
the Node's [.spec](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeSpec)
- Learn more about kubelet configuration by checking the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
reference.

1
content/en/docs/tasks/administer-cluster/sysctl-cluster.md
View File

@ -71,6 +71,7 @@ The following sysctls are supported in the _safe_ set:
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`,
- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
- `net.ipv4.ip_unprivileged_port_start` (since Kubernetes 1.22).
{{< note >}}
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.

6
content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
View File

@ -236,8 +236,14 @@ sudo rmdir /mnt/data
You can now close the shell to your Node.
## Mounting the same persistentVolume in two places
{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
You can perform 2 volume mounts on your nginx container:
`/usr/share/nginx/html` for the static website
`/etc/nginx/nginx.conf` for the default config
<!-- discussion -->

1
content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md
View File

@ -73,6 +73,7 @@ isolation other than resource constraints imposed on the HostProcess user accoun
filesystem or Hyper-V isolation are supported for HostProcess containers.
- Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts)
- As of 1.23, a limited set of host user accounts are available for HostProcess containers by default.
- A limited set of host user accounts are available for HostProcess containers by default.
See [Choosing a User Account](#choosing-a-user-account).
- Resource limits (disk, memory, cpu count) are supported in the same fashion as processes
on the host.

122
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
View File

@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
```sh
# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose
# macOS
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose
# Windows
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose
@ -207,8 +207,6 @@ you need is an existing `docker-compose.yml` file.
- CLI
- [`kompose convert`](#kompose-convert)
- [`kompose up`](#kompose-up)
- [`kompose down`](#kompose-down)
- Documentation
- [Build and Push Docker Images](#build-and-push-docker-images)
- [Alternative Conversions](#alternative-conversions)
@ -328,121 +326,7 @@ INFO OpenShift file "foo-buildconfig.yaml" created
If you are manually pushing the OpenShift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this OpenShift issue: https://github.com/openshift/origin/issues/4518 .
{{< /note >}}
## `kompose up`
Kompose supports a straightforward way to deploy your "composed" application to Kubernetes or OpenShift via `kompose up`.
### Kubernetes `kompose up` example
```shell
kompose --file ./examples/docker-guestbook.yml up
```
```none
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created deployment: frontend
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
```
```shell
kubectl get deployment,svc,pods
```
```none
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.extensions/frontend 1 1 1 1 4m
deployment.extensions/redis-master 1 1 1 1 4m
deployment.extensions/redis-slave 1 1 1 1 4m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/frontend ClusterIP 10.0.174.12 <none> 80/TCP 4m
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 13d
service/redis-master ClusterIP 10.0.202.43 <none> 6379/TCP 4m
service/redis-slave ClusterIP 10.0.1.85 <none> 6379/TCP 4m
NAME READY STATUS RESTARTS AGE
pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
```
{{< note >}}
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl apply -f` commands instead.
{{< /note >}}
### OpenShift `kompose up` example
```shell
kompose --file ./examples/docker-guestbook.yml --provider openshift up
```
```none
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created service: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created ImageStream: redis-slave
INFO Successfully created deployment: frontend
INFO Successfully created ImageStream: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created ImageStream: redis-master
Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details.
```
```shell
oc get dc,svc,is
```
```none
NAME REVISION DESIRED CURRENT TRIGGERED BY
dc/frontend 0 1 0 config,image(frontend:v4)
dc/redis-master 0 1 0 config,image(redis-master:e2e)
dc/redis-slave 0 1 0 config,image(redis-slave:v1)
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/frontend 172.30.46.64 <none> 80/TCP 8s
svc/redis-master 172.30.144.56 <none> 6379/TCP 8s
svc/redis-slave 172.30.75.245 <none> 6379/TCP 8s
NAME DOCKER REPO TAGS UPDATED
is/frontend 172.30.12.200:5000/fff/frontend
is/redis-master 172.30.12.200:5000/fff/redis-master
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
```
{{< note >}}
You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`).
{{< /note >}}
## `kompose down`
Once you have deployed "composed" application to Kubernetes, `kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
```shell
kompose --file docker-guestbook.yml down
INFO Successfully deleted service: redis-master
INFO Successfully deleted deployment: redis-master
INFO Successfully deleted service: redis-slave
INFO Successfully deleted deployment: redis-slave
INFO Successfully deleted service: frontend
INFO Successfully deleted deployment: frontend
```
{{< note >}}
You must have a running Kubernetes cluster with a pre-configured `kubectl` context.
{{< /note >}}
## Build and Push Docker Images

16
content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
View File

@ -1038,8 +1038,8 @@ procedure.
*Option 1:* Use the Storage Version Migrator
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
*Option 2:* Manually upgrade the existing objects to a new stored version
@ -1050,6 +1050,16 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
2. Write an upgrade procedure to list all existing objects and write them with
the same content. This forces the backend to write objects in the current
storage version, which is `v1`.
2. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
3. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
{{< note >}}
The `kubectl` tool currently cannot be used to edit or patch the `status` subresource on a CRD: see the [Kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) for more details.
The easier way to patch the status subresource from the CLI is directly interacting with the API server using the `curl` tool, in this example:
```bash
kubectl proxy &
curl --header "Content-Type: application/json-patch+json" \
--request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/<your CRD name here>/status \
--data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]'
```
{{< /note >}}

10
content/en/docs/tasks/job/parallel-processing-expansion.md
View File

@ -178,13 +178,13 @@ First, copy and paste the following template of a Job object, into a file called
```liquid
{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
{ "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
{ "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
%}
{%- for p in params %}
{%- set name = p["name"] %}
{%- set url = p["url"] %}
{% for p in params %}
{% set name = p["name"] %}
{% set url = p["url"] %}
---
apiVersion: batch/v1
kind: Job
@ -204,7 +204,7 @@ spec:
image: busybox
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
{%- endfor %}
{% endfor %}
```
The above template defines two parameters for each Job object using a list of

39
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -525,6 +525,45 @@ stops adjusting the target (and sets the `ScalingActive` Condition on itself
to `false`) until you reactivate it by manually adjusting the target's desired
replica count or HPA's minimum replica count.
### Migrating Deployments and StatefulSets to horizontal autoscaling
When an HPA is enabled, it is recommended that the value of `spec.replicas` of
the Deployment and / or StatefulSet be removed from their
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
a change to that object is applied, for example via `kubectl apply -f
deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
to the value of the `spec.replicas` key. This may not be
desired and could be troublesome when an HPA is active.
Keep in mind that the removal of `spec.replicas` may incur a one-time
degradation of Pod counts as the default value of this key is 1 (reference
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas).
Upon the update, all Pods except 1 will begin their termination procedures. Any
deployment application afterwards will behave as normal and respect a rolling
update configuration as desired. You can avoid this degradation by choosing one of the following two
methods based on how you are modifying your deployments:
{{< tabs name="fix_replicas_instructions" >}}
{{% tab name="Client Side Apply (this is the default)" %}}
1. `kubectl apply edit-last-applied deployment/<deployment_name>`
2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
applies the update. No changes to Pod counts happen at this step.
3. You can now remove `spec.replicas` from the manifest. If you use source code management,
also commit your changes or take whatever other steps for revising the source code
are appropriate for how you track updates.
4. From here on out you can run `kubectl apply -f deployment.yaml`
{{% /tab %}}
{{% tab name="Server Side Apply" %}}
When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/)
you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership)
guidelines, which cover this exact use case.
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
If you configure autoscaling in your cluster, you may also want to consider running a

20
content/en/examples/pods/storage/pv-duplicate.yaml Normal file
View File

@ -0,0 +1,20 @@
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: test
image: nginx
volumeMounts:
- name: site-data
mountPath: /usr/share/nginx/html
subPath: html
- name: config
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: config
persistentVolumeClaim:
claimName: test-nfs-claim

2
content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -233,7 +233,7 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
Menginstal crictl (dibutuhkan untuk kubeadm / Kubelet Container Runtime Interface (CRI))
```bash
CRICTL_VERSION="v1.17.0"
CRICTL_VERSION="v1.22.0"
ARCH="amd64"
mkdir -p /opt/bin
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

2
content/ko/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -67,4 +67,4 @@ SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

100
content/ko/docs/concepts/architecture/nodes.md
View File

@ -51,7 +51,7 @@ weight: 10
```
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다.
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
대해 무시된다.
@ -72,15 +72,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
상태(예: 네트워크 설정, 루트 디스크 내용)와 노드 레이블과 같은 동일한 속성(attribute)을
갖는다고 암시적으로 가정한다. 인스턴스가
이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
업데이트 후 다시 추가해야 한다.
### 노드에 대한 자체-등록
### 노드에 대한 자체-등록(self-registration)
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API 서버에
스스로 등록을 시도할 것이다. 이는 선호되는 패턴이며, 대부분의 배포판에서 사용된다.
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
@ -96,7 +97,22 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
[Node authorization mode](/docs/reference/access-authn-authz/node/)와
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다.
{{< note >}}
[노드 이름 고유성](#노드-이름-고유성) 섹션에서 언급했듯이,
노드 구성을 업데이트해야 하는 경우 API 서버에 노드를
다시 등록하는 것이 좋다. 예를 들어 kubelet이 `--node-labels`의 새로운 구성으로
다시 시작되더라도, 동일한 노드 이름이 사용된 경우
레이블이 해당 노드의 등록에 설정되기 때문에 변경 사항이 적용되지 않는다.
노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우
오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에
할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는
새 레이블을 기반으로 스케줄링된다. 노드 재등록(re-registration)은 모든 파드를
비우고(drain) 다시 적절하게 스케줄링되도록
한다.
{{< /note >}}
#### 수동 노드 관리
@ -146,7 +162,7 @@ kubectl cordon $NODENAME
kubectl describe node <insert-node-name-here>
```
출력되는 각 섹션은 아래에 설명되어있다.
출력되는 각 섹션은 아래에 설명되어 있다.
### 주소 {#addresses}
@ -177,7 +193,8 @@ kubectl describe node <insert-node-name-here>
대신 코드화된 노드는 사양에 스케줄 불가로 표시된다.
{{< /note >}}
쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.
쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에
표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.
```json
"conditions": [
@ -208,12 +225,14 @@ API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
쿠버네티스에서 노드 오브젝트를 삭제하면
노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며
파드가 사용하던 이름을 다시 사용할 수 있게 된다.
노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는
[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를
생성한다.
스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다.
또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록
{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다.
@ -235,9 +254,11 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
### 정보
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다.
이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다.
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너
런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은
노드에 대한 일반적인 정보가 기술된다.
이 정보는 Kubelet이 노드에서 수집하여
쿠버네티스 API로 전송한다.
## 하트비트
@ -248,20 +269,25 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
* 노드의 `.status`에 대한 업데이트
* `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트.
각 노드는 연관된 리스 오브젝트를 갖는다.
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}}
내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다.
노드의 `.status`와 비교해서, 리스는 경량의 리소스이다.
큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다.
노드의 `.status`에 비하면, 리스는 경량의 리소스이다.
큰 규모의 클러스터에서는 리스를 하트비트에 사용하여
업데이트로 인한 성능 영향을 줄일 수 있다.
kubelet은 노드의 `.status` 생성과 업데이트 및
관련된 리스의 업데이트를 담당한다.
- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다.
노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다.
- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다.
리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다.
만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우
노드의 `.status`를 업데이트한다. 노드의 `.status` 업데이트에 대한 기본
인터벌은 접근이 불가능한 노드에 대한 타임아웃인
40초 보다 훨씬 긴 5분이다.
- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다
생성하고 업데이트한다. 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다.
만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고
7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
### 노드 컨트롤러
@ -278,13 +304,16 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는
다음을 담당한다.
- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다.
- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status`
내에 있는 NodeReady 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다.
기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다.
- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
트리거한다. 기본적으로, 노드 컨트롤러는 노드를
`ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
최초의 축출 요청을 시작한다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
@ -315,7 +344,10 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
`--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이
완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다.
이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.)
이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가
있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가
다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한
나머지 노드에서 파드를 축출한다.)
또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의
노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다.
@ -377,19 +409,19 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.

2
content/ko/docs/concepts/cluster-administration/_index.md
View File

@ -57,7 +57,7 @@ no_list: true
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.

2
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
View File

@ -105,5 +105,5 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.

8
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -145,7 +145,7 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
### 콘티브(Contiv)
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
@ -260,12 +260,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://
[NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
### Nuage Networks VCS(가상 클라우드 서비스)
[Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
### OpenVSwitch
[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만

14
content/ko/docs/concepts/configuration/secret.md
View File

@ -37,7 +37,7 @@ weight: 30
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
활성화 또는 구성.
3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
{{< /caution >}}
@ -425,9 +425,9 @@ stringData:
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
## 시크릿 편집하기
@ -1259,7 +1259,7 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
- [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기

2
content/ko/docs/concepts/containers/_index.md
View File

@ -22,7 +22,7 @@ no_list: true
## 컨테이너 이미지
[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다.
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다.

2
content/ko/docs/concepts/containers/container-environment.md
View File

@ -32,7 +32,7 @@ weight: 20
함수 호출을 통해서 구할 수 있다.
파드 이름과 네임스페이스는
[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.

23
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -2,6 +2,11 @@
title: 쿠버네티스 확장
weight: 110
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
feature:
title: 확장성을 고려하여 설계됨
description: >
@ -47,9 +52,9 @@ no_list: true
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
많은 클러스터 관리자가 호스팅 또는 배포판 쿠버네티스 인스턴스를 사용한다.
이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의
쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다.
## 익스텐션 패턴
@ -74,14 +79,12 @@ no_list: true
바이너리 플러그인은 kubelet(예:
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서
사용한다.
kubectl에서 사용한다.
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
보여주는 다이어그램이다.
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png)
## 익스텐션 포인트
@ -89,7 +92,6 @@ kubectl에서
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
@ -103,10 +105,10 @@ kubectl에서
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
## API 익스텐션
### 사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
@ -155,7 +157,6 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
## 인프라스트럭처 익스텐션
### 스토리지 플러그인
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
@ -172,7 +173,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
### 네트워크 플러그인
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
### 스케줄러 익스텐션
@ -200,3 +202,4 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기

2
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
View File

@ -85,7 +85,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다.
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다.
```json
{

8
content/ko/docs/concepts/overview/components.md
View File

@ -1,4 +1,6 @@
---
title: 쿠버네티스 컴포넌트
content_type: concept
description: >
@ -17,11 +19,7 @@ card:
이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
다양한 컴포넌트들에 대해 요약하고 정리한다.
여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다.
![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.svg)
{{< figure src="/images/docs/components-of-kubernetes.svg" alt="쿠버네티스 구성 요소" caption="쿠버네티스 클러스터 구성 요소" class="diagram-large" >}}
<!-- body -->
## 컨트롤 플레인 컴포넌트

6
content/ko/docs/concepts/overview/working-with-objects/labels.md
View File

@ -50,7 +50,7 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하여야 하고 (공백일 수도 있음),
@ -95,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
{{< /note >}}
{{< caution >}}
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.
{{< /caution >}}
### _일치성 기준_ 요건
@ -231,7 +231,7 @@ selector:
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.
#### 노드 셋 선택

7
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -1,4 +1,8 @@
---
title: 네임스페이스
content_type: concept
weight: 30
@ -6,8 +10,7 @@ weight: 30
<!-- overview -->
쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
이런 가상 클러스터를 네임스페이스라고 한다.
쿠버네티스에서, _네임스페이스_ 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 _(예: 디플로이먼트, 서비스 등)_ 에만 적용 가능하며 클러스터 범위의 오브젝트 _(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)_ 에는 적용 불가능하다.
<!-- body -->

2
content/ko/docs/concepts/policy/pod-security-policy.md
View File

@ -695,7 +695,7 @@ spec:
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
[Sysctl 문서](
/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다.
/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/scheduling-eviction/_index.md
View File

@ -33,5 +33,5 @@ no_list: true
{{<glossary_definition term_id="pod-disruption" length="all">}}
* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)

2
content/ko/docs/concepts/scheduling-eviction/api-eviction.md
View File

@ -14,5 +14,5 @@ API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-ap
## {{% heading "whatsnext" %}}
- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기

2
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -265,7 +265,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다).
생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
연관된 `matchExpressions` 가 모두 충족되어야 한다.

2
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -91,5 +91,5 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기
* [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)
* [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/)
* [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/)
* [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/)

6
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -48,7 +48,7 @@ weight: 70
{{< note >}}
쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`,
두 개의 프라이어리티클래스를 제공한다.
이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
{{< /note >}}
## 프라이어리티클래스
@ -357,11 +357,11 @@ kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure)
사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
1. 부족한 리소스 사용량이 요청을 초과하는지 여부
1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부
1. 파드 우선순위
1. 요청 대비 리소스 사용량
더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
참조한다.
kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우

12
content/ko/docs/concepts/security/overview.md
View File

@ -29,7 +29,7 @@ weight: 1
널리 알려져 있다.
{{< /note >}}
{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}}
{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" class="diagram-large" >}}
클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다.
코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다.
@ -77,7 +77,7 @@ API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스
노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다.
클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다.
etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다.
etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.
etcd 암호화 | 가능한 한 모든 스토리지를 암호화하는 것이 좋은 방법이며, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.
{{< /table >}}
@ -107,9 +107,9 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
------------------------------ | ------------ |
RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/
애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/ko/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
파드가 파드 시큐리티 폴리시를 만족하는지 확인하기 | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/ko/docs/tasks/configure-pod-container/quality-service-pod/
네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls
@ -137,7 +137,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r
코드에서 고려할 영역 | 추천 |
-------------------------| -------------- |
TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. |
TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 실행하는 [mTLS(상호 TLS 인증)](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. |
통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. |
타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. |
정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools |

4
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -56,7 +56,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
`kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
@ -346,7 +346,7 @@ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
준비가 되어있다.
준비가 되어 있다.
```shell
kubectl get svc my-nginx -o yaml | grep nodePort -C 5

2
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -233,7 +233,7 @@ DNS 정책은 파드별로 설정할 수 있다.
자세한 내용을 확인할 수 있다.
{{< note >}}
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어 있지 않다면
"ClusterFirst"가 기본값으로 사용된다.
{{< /note >}}

2
content/ko/docs/concepts/services-networking/ingress-controllers.md
View File

@ -76,4 +76,4 @@ weight: 40
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/).

4
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -77,7 +77,7 @@ graph LR;
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
@ -567,4 +567,4 @@ Events:
* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/)
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/)

2
content/ko/docs/concepts/services-networking/network-policies.md
View File

@ -96,7 +96,7 @@ __podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드
__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.

2
content/ko/docs/concepts/services-networking/service-topology.md
View File

@ -96,7 +96,7 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노
* 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
`topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
* 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.

2
content/ko/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기
* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

7
content/ko/docs/concepts/services-networking/service.md
View File

@ -263,9 +263,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어,
운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다.
마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
@ -1074,6 +1072,9 @@ spec:
{{< /note >}}
엘라스틱 IP에 대한 설명 문서와 기타 일반적 사용 사례를
[AWS 로드 밸런서 컨트롤러 문서](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)에서 볼 수 있다.
#### Tencent Kubernetes Engine (TKE)의 다른 CLB 어노테이션
아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다.

4
content/ko/docs/concepts/storage/volumes.md
View File

@ -280,7 +280,7 @@ spec:
업데이트를 수신하지 않는다.
{{< /note >}}
더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
### emptyDir {#emptydir}
@ -358,7 +358,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
`flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약
Flocker내에 데이터셋이 없는 경우, 먼저 Flocker
CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면
Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에
Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이는 필요에
따라 파드 간에 데이터를 공유할 수 있다는 의미이다.
{{< note >}}

2
content/ko/docs/concepts/workloads/_index.md
View File

@ -60,7 +60,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/)
* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)

1
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -77,6 +77,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
`CRON_TZ=UTC 0 0 13 * 5`

4
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
일반적인 설정파일 작업에 대한 정보는
[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
[스테이트리스 애플리케이션 실행하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
[kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
데몬셋 오브젝트의 이름은 유효한
@ -166,7 +166,7 @@ nodeAffinity:
데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
구성되어 있다. 그들은 클라이언트들을 가지지 않는다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며,
노드IP를 통해 파드에 접근할 수 있다.
클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.

55
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -1,4 +1,6 @@
---
title: 디플로이먼트
feature:
title: 자동화된 롤아웃과 롤백
@ -50,13 +52,13 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
보다 정교한 선택 규칙의 적용이 가능하다.
{{< note >}}
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어 있다. `matchLabels` 에 매핑된
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
`value` 배열은 "value"만 포함한다.
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
{{< /note >}}
* `template` 필드에는 다음 하위 필드가 포함되어있다.
* `template` 필드에는 다음 하위 필드가 포함되어 있다.
* 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다.
* 파드 템플릿의 사양 또는 `.template.spec` 필드는
파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는
@ -74,7 +76,6 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
@ -163,7 +164,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
```shell
kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
또는 다음의 명령어를 사용한다.
@ -181,7 +182,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다.
```shell
kubectl edit deployment.v1.apps/nginx-deployment
kubectl edit deployment/nginx-deployment
```
다음과 유사하게 출력된다.
@ -364,7 +365,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
이와 유사하게 출력된다.
@ -473,25 +474,25 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
1. 먼저 이 디플로이먼트의 수정 사항을 확인한다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
kubectl rollout history deployment/nginx-deployment
```
이와 유사하게 출력된다.
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
`CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
* 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* 디플로이먼트에 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* 수동으로 리소스 매니페스트 편집.
2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
kubectl rollout history deployment/nginx-deployment --revision=2
```
이와 유사하게 출력된다.
@ -499,7 +500,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@ -516,7 +517,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
1. 이제 현재 롤아웃의 실행 취소 및 이전 수정 버전으로 롤백 하기로 결정했다.
```shell
kubectl rollout undo deployment.v1.apps/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -526,7 +527,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
```shell
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
kubectl rollout undo deployment/nginx-deployment --to-revision=2
```
이와 유사하게 출력된다.
@ -560,7 +561,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@ -603,7 +604,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
다음 명령어를 사용해서 디플로이먼트의 스케일을 할 수 있다.
```shell
kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
kubectl scale deployment/nginx-deployment --replicas=10
```
이와 유사하게 출력된다.
```
@ -615,7 +616,7 @@ deployment.apps/nginx-deployment scaled
실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다.
```shell
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
```
이와 유사하게 출력된다.
```
@ -644,7 +645,7 @@ deployment.apps/nginx-deployment scaled
* 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
kubectl set image deployment/nginx-deployment nginx=nginx:sometag
```
이와 유사하게 출력된다.
@ -723,7 +724,7 @@ nginx-deployment-618515232 11 11 11 7m
* 다음 명령을 사용해서 일시 중지한다.
```shell
kubectl rollout pause deployment.v1.apps/nginx-deployment
kubectl rollout pause deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -733,7 +734,7 @@ nginx-deployment-618515232 11 11 11 7m
* 그런 다음 디플로이먼트의 이미지를 업데이트 한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
이와 유사하게 출력된다.
@ -743,7 +744,7 @@ nginx-deployment-618515232 11 11 11 7m
* 새로운 롤아웃이 시작되지 않는다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
kubectl rollout history deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -765,7 +766,7 @@ nginx-deployment-618515232 11 11 11 7m
* 예를 들어 사용할 리소스를 업데이트하는 것처럼 원하는 만큼 업데이트할 수 있다.
```shell
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
```
이와 유사하게 출력된다.
@ -778,7 +779,7 @@ nginx-deployment-618515232 11 11 11 7m
* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
```shell
kubectl rollout resume deployment.v1.apps/nginx-deployment
kubectl rollout resume deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -888,7 +889,7 @@ echo $?
10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
```shell
kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
```
이와 유사하게 출력된다.
```
@ -999,7 +1000,7 @@ Conditions:
`kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
```
@ -1023,7 +1024,7 @@ echo $?
디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서
디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다.
기본적으로 10으로 되어있다.
기본적으로 10으로 되어 있다.
{{< note >}}
명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고,
@ -1040,7 +1041,7 @@ echo $?
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다.
설정 파일 작업에 대한 일반적인 내용은
[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
[애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/),
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
디플로이먼트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

24
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -144,19 +144,19 @@ kubectl logs $pods
잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다.
1. 비-병렬(Non-parallel) 잡:
- 일반적으로, 파드가 실패하지 않은 한, 하나의 파드만 시작된다.
- 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다.
- 일반적으로, 파드가 실패하지 않은 한, 하나의 파드만 시작된다.
- 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다.
1. *고정적(fixed)인 완료 횟수* 를 가진 병렬 잡:
- `.spec.completions` 에 0이 아닌 양수 값을 지정한다.
- 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다.
- `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다.
- `.spec.completions` 에 0이 아닌 양수 값을 지정한다.
- 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다.
- `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다.
1. *작업 큐(queue)* 가 있는 병렬 잡:
- `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다.
- 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다.
- 각 파드는 모든 피어들의 작업이 완료되었는지 여부를 독립적으로 판단할 수 있으며, 결과적으로 전체 잡이 완료되게 한다.
- 잡의 _모든_ 파드가 성공적으로 종료되면, 새로운 파드는 생성되지 않는다.
- 하나 이상의 파드가 성공적으로 종료되고, 모든 파드가 종료되면 잡은 성공적으로 완료된다.
- 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 해당 작업을 지속하지 않아야 하며 어떠한 출력도 작성하면 안 된다. 파드들은 모두 종료되는 과정에 있어야 한다.
- `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다.
- 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다.
- 각 파드는 모든 피어들의 작업이 완료되었는지 여부를 독립적으로 판단할 수 있으며, 결과적으로 전체 잡이 완료되게 한다.
- 잡의 _모든_ 파드가 성공적으로 종료되면, 새로운 파드는 생성되지 않는다.
- 하나 이상의 파드가 성공적으로 종료되고, 모든 파드가 종료되면 잡은 성공적으로 완료된다.
- 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 해당 작업을 지속하지 않아야 하며 어떠한 출력도 작성하면 안 된다. 파드들은 모두 종료되는 과정에 있어야 한다.
_비-병렬_ 잡은 `.spec.completions` 와 `.spec.parallelism` 모두를 설정하지 않은 채로 둘 수 있다. 이때 둘 다
설정하지 않은 경우 1이 기본으로 설정된다.
@ -369,7 +369,7 @@ spec:
다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다.
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |

10
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -50,7 +50,7 @@ OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고
{{< codenew file="controllers/frontend.yaml" >}}
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어 있는 레플리카셋이
생성되고 레플리카셋이 관리하는 파드가 생성된다.
```shell
@ -128,7 +128,7 @@ frontend-wtsmm 1/1 Running 0 6m36s
kubectl get pods frontend-b2zdv -o yaml
```
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
```shell
apiVersion: v1
@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
레플리카셋 오브젝트의 이름은 유효한
@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
### 파드 템플릿
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
`.spec.template`은 레이블을 붙이도록 되어 있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
@ -269,7 +269,7 @@ matchLabels:
### 레플리카셋과 해당 파드 삭제
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
설정해야 한다.

1
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -118,7 +118,6 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
## 레플리케이션 컨트롤러의 Spec 작성
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.

2
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -189,7 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
* 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
* 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
배포된다. web-1은 web-0이

17
content/ko/docs/concepts/workloads/pods/_index.md
View File

@ -48,6 +48,21 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
## 파드의 사용
다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다.
{{< codenew file="pods/simple-pod.yaml" >}}
위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
```
일반적으로 파드는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다.
[파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한
더 많은 정보를 확인한다.
### Workload resources for managing pods
일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)"
term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다.
파드가 상태를 추적해야 한다면,
@ -97,7 +112,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
별도의 "사이드카" 컨테이너가 있을 수 있다.
{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}}
{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}}
일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.

4
content/ko/docs/concepts/workloads/pods/disruptions.md
View File

@ -31,7 +31,7 @@ weight: 60
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면
@ -71,7 +71,7 @@ weight: 60
- 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
(복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및
[스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)

2
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -76,4 +76,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
## {{% heading "whatsnext" %}}
* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.

2
content/ko/docs/concepts/workloads/pods/init-containers.md
View File

@ -283,7 +283,7 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`를 사용한다.
Active deadline은 초기화 컨테이너를 포함한다.
그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
그러나 팀에서 애플리케이션을 잡(job)으로 배포한 경우에만 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤

4
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -55,7 +55,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고
새로 생성된다.
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
{{< figure src="/images/docs/pod.svg" title="Pod diagram" class="diagram-medium" >}}
*컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와
파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.*
@ -433,7 +433,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
작은 유예 기간이 계속 제공된다.
스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우,
[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
[스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
태스크 문서를 참고한다.
### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection}

62
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -234,43 +234,43 @@ graph BT
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다.

95
content/ko/docs/contribute/_index.md
View File

@ -29,6 +29,8 @@ card:
- 문서를 번역합니다.
- 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다.
<!-- body -->
## 시작하기
@ -44,19 +46,99 @@ card:
문서에 참여하려면
1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
2. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
[정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
[변경 검토](/ko/docs/contribute/review/reviewing-prs/)의
기본 프로세스를 이해하도록 합니다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart TB
subgraph third[PR 열기]
direction TB
U[ ] -.-
Q[컨텐츠 향상시키기] --- N[컨텐츠 생성하기]
N --- O[문서 번역하기]
O --- P[K8s 릴리스 사이클의 문서 파트<br>관리/퍼블리싱하기]
end
subgraph second[리뷰]
direction TB
T[ ] -.-
D[K8s/website<br>저장소 살펴보기] --- E[Hugo 정적 사이트<br>생성기 확인하기]
E --- F[기본 GitHub 명령어<br>이해하기]
F --- G[열려 있는 PR을 리뷰하기]
end
subgraph first[가입]
direction TB
S[ ] -.-
B[CNCF<br>Contributor<br>License Agreement<br>서명하기] --- C[sig-docs 슬랙 채널<br>가입하기]
C --- V[kubernetes-sig-docs<br>메일링 리스트 가입하기]
V --- M[주간<br>sig-docs 회의/<br>슬랙 미팅 참여하기]
end
A([fa:fa-user 신규<br>기여자]) --> first
A --> second
A --> third
A --> H[질문하세요!!!]
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
class S,T,U spacewhite
class first,second,third white
{{</ mermaid >}}
***그림 - 신규 기여자를 위한 시작 가이드***
위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
역할과 권한에 대한 자세한 내용은
[SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다.
## 첫 번째 기여
- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고
몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph second[첫 기여]
direction TB
S[ ] -.-
G[다른 K8s 멤버의 PR 리뷰하기] -->
A[K8s/website 이슈 리스트에서<br>good first issue 확인하기] --> B[PR을 여세요!!]
end
subgraph first[추천 준비 사항]
direction TB
T[ ] -.-
D[기여 개요 읽기] -->E[K8s 컨텐츠 및 <br>스타일 가이드 읽기]
E --> F[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,D,E,F,G grey
class S,T spacewhite
class first,second white
{{</ mermaid >}}
***그림 - 첫 기여를 위한 준비***
- [기여 개요](/ko/docs/contribute/new-content/)를 읽고
기여할 수 있는 다양한 방법에 대해 알아봅니다.
- [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
@ -92,10 +174,13 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.
자신을 소개하세요!
- 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는
[`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요.
- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
- 2주마다 열리는 [SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 공지되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
- 줌 화상 회의가 열리지 않은 경우, SIG Docs 비실시간 슬랙 스탠드업 회의에 참여하세요. 회의는 항상 `#sig-docs` 에 공지됩니다. 회의 공지 후 24시간까지 어느 스레드에나 기여할 수 있습니다.
## 다른 기여 방법들
- [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
- [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다.
- [기여자 치트시트](https://www.kubernetes.dev/docs/contributor-cheatsheet/)를 읽고 쿠버네티스 기능 개발에 참여합니다.
- 쿠버네티스 기여자 사이트에서 [쿠버네티스 기여자](https://www.kubernetes.dev/)와 [추가적인 기여자 리소스](https://www.kubernetes.dev/resources/)에 대해 더 알아봅니다.
- [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다.

2
content/ko/docs/contribute/advanced.md
View File

@ -8,7 +8,7 @@ weight: 98
<!-- overview -->
이 페이지에서는 당신이
[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/overview)하고
[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/)하고
[다른 사람의 작업을 리뷰](/ko/docs/contribute/review/reviewing-prs/)하는 방법을
이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한
작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다.

84
content/ko/docs/contribute/new-content/_index.md
View File

@ -5,10 +5,48 @@ main_menu: true
weight: 20
---
<!-- overview -->
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가
있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph second[시작하기 전에]
direction TB
S[ ] -.-
A[CNCF CLA 서명하기] --> B[Git 브랜치 선택하기]
B --> C[한 PR에는 한 언어에 대한 변경사항만]
C --> F[기여자 도구 확인하기]
end
subgraph first[기여 기초]
direction TB
T[ ] -.-
D[문서를 마크다운으로 작성하고<br>Hugo로 사이트 빌드] --- E[GitHub에 있는 소스]
E --- G['/content/../docs' 폴더에<br>각 언어 컨텐츠가 있음]
G --- H[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H grey
class S,T spacewhite
class first,second white
{{</ mermaid >}}
***Figure - Contributing new content preparation***
The figure above depicts the information you should know
prior to submitting new content. The information details follow.
@ -16,28 +54,43 @@ weight: 20
## 기여에 대한 기본 사항
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고
[Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다.
쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다.
일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여
자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은
Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여
콘텐츠 표시를 제어한다.
- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각
언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에
의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어,
한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
- 여러 언어로 문서화에 기여하거나
새로운 번역을 시작하는 방법에 대한 자세한 내용은
[현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
## 시작하기 전에 {#before-you-begin}
### CNCF CLA 서명 {#sign-the-cla}
모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
모든 쿠버네티스 기여자는 **반드시**
[기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고
[기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다
.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다.
제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며,
git 이름과 이메일은 CNCF CLA에 사용된 것과
일치해야 한다.
### 사용할 Git 브랜치를 선택한다
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를
미리 알아야 한다.
시나리오 | 브랜치
:---------|:------------
@ -45,20 +98,21 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
{{< note >}}
풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
{{< note >}} 풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
제출자(제출자인 여러분만)가 이를 변경할 수 있다.
{{< /note >}}
### PR 당 언어
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
PR 당 하나의 언어로 풀 리퀘스트를 제한한다.
여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우
각 언어마다 별도의 PR을 연다.
## 기여자를 위한 도구들
`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.
`kubernetes/website` 리포지터리의
[문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.

103
content/ko/docs/contribute/new-content/open-a-pr.md
View File

@ -15,7 +15,7 @@ card:
[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
{{< /note >}}
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
@ -28,7 +28,40 @@ card:
## GitHub을 사용하여 변경하기
git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를
여는 쉬운 방법이 있다.
여는 쉬운 방법이 있다. 아래의 그림은 각 단계를 보여주며, 상세사항은 그 아래에 나온다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
A([fa:fa-user 신규<br>기여자]) --- id1[(K8s/Website<br>GitHub)]
subgraph tasks[GitHub 상에서 변경하기]
direction TB
0[ ] -.-
1[1. '페이지 편집' 누르기] --> 2[2. GitHub 마크다운<br>편집기로 편집하기]
2 --> 3[3. 'Propose file change'에<br>추가 내용 기재하기]
end
subgraph tasks2[ ]
direction TB
4[4. 'Propose changes' 누르기] --> 5[5. 'Create pull request' 누르기] --> 6[6. 'Open a pull request'에<br>추가 내용 기재하기]
6 --> 7[7. 'Create pull request' 누르기]
end
id1 --> tasks --> tasks2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,1,2,3,4,5,6,7 grey
class 0 spacewhite
class tasks,tasks2 white
class id1 k8s
{{</ mermaid >}}
***그림 - GitHub 상에서 PR을 여는 단계***
1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
@ -89,6 +122,37 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
1[K8s/website<br>저장소 포크하기] --> 2[로컬 클론 생성<br>및 upstream 설정]
subgraph changes[당신의 변경사항]
direction TB
S[ ] -.-
3[브랜치 생성<br>예: my_new_branch] --> 3a[텍스트 편집기로<br>변경사항 만들기] --> 4["Hugo (localhost:1313)<br>를 이용하거나<br>컨테이너 이미지를 빌드하여<br>변경사항을 로컬에서 미리보기"]
end
subgraph changes2[커밋 / 푸시]
direction TB
T[ ] -.-
5[변경사항 커밋하기] --> 6[커밋을<br>origin/my_new_branch<br>로 푸시하기]
end
2 --> changes --> changes2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class 1,2,3,3a,4,5,6 grey
class S,T spacewhite
class changes,changes2 white
{{</ mermaid >}}
***그림 - 로컬 포크에서 변경 사항 작업하기***
### kubernetes/website 리포지터리 포크하기
1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
@ -230,7 +294,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
1. 로컬에서 이미지를 빌드한다.
```bash
make docker-image
# docker 사용(기본값)
make container-image
@ -243,7 +306,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
```bash
make docker-serve
# docker 사용(기본값)
make container-serve
@ -291,6 +353,34 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph first[ ]
direction TB
1[1. K8s/website 저장소로 이동] --> 2[2. 'New Pull Request' 클릭]
2 --> 3[3. 'Compare across forks' 클릭]
3 --> 4[4. 'head repository' 드롭다운 메뉴에서<br>당신의 포크 선택]
end
subgraph second [ ]
direction TB
5[5. 'compare' 드롭다운 메뉴에서<br>당신의 브랜치 선택] --> 6[6. 'Create Pull Request' 클릭]
6 --> 7[7. PR 본문에 상세 설명 기재]
7 --> 8[8. 'Create pull request' 클릭]
end
first --> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
class 1,2,3,4,5,6,7,8 grey
class first,second white
{{</ mermaid >}}
***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
2. **New Pull Request** 를 선택한다.
3. **compare across forks** 를 선택한다.
@ -305,7 +395,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
8. **Create pull request** 버튼을 선택한다.
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
@ -416,7 +506,6 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
풀 리퀘스트에 더 이상 충돌이 표시되지 않는다.
### 커밋 스쿼시하기
{{< note >}}
@ -502,8 +591,6 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
가능한 한 상세하게 템플릿의 내용을 작성한다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/contribute/participate/_index.md
View File

@ -116,6 +116,6 @@ PR 소유자에게 조언하는데 활용된다.
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)

2
content/ko/docs/contribute/participate/roles-and-responsibilities.md
View File

@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
- [슬랙](https://slack.k8s.io/) 또는
[SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.

38
content/ko/docs/contribute/review/reviewing-prs.md
View File

@ -18,7 +18,8 @@ weight: 10
- 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
- 쿠버네티스 문서화 커뮤니티의 다양한
[역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다.
[역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을
이해한다.
<!-- body -->
@ -35,7 +36,38 @@ weight: 10
## 리뷰 과정
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다.
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph fourth[리뷰 시작]
direction TB
S[ ] -.-
M[코멘트 작성] --> N[변경사항 리뷰]
N --> O[새 기여자가 어떤 코멘트를<br>반영할지 선택해야 함]
end
subgraph third[PR 선택]
direction TB
T[ ] -.-
J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로<br>변경사항 미리보기]
end
A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여<br>PR을 필터링]
B --> third --> fourth
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,J,K,M,N,O grey
class S,T spacewhite
class third,fourth white
{{</ mermaid >}}
***그림 - 리뷰 과정 절차***
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
이동한다.
@ -43,7 +75,7 @@ weight: 10
표시된다.
2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다.
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다.
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다.
- `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다.
- `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.

2
content/ko/docs/contribute/style/write-new-topic.md
View File

@ -105,7 +105,7 @@ YAML 블록이다. 여기 예시가 있다.
포함할 수 있다.
- 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에
불완전한 예제다. 예를 들어 몇 가지 이유로
[PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
[PodSecurityPolicy](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)
를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다.
- 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어
`kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을

15
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -134,6 +134,21 @@ kubectl auth can-i list secrets --namespace dev --as dave
no
```
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스 어카운트가
`target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.
```bash
kubectl auth can-i list pods \
--namespace target \
--as system:serviceaccount:dev:dev-sa
```
다음과 유사하게 출력된다.
```
yes
```
`SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서
API 서버 인가를 외부 서비스에 노출시킨다.
이 그룹의 기타 리소스에는 다음이 포함된다.

20
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -125,7 +125,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
| `IndexedJob` | `true` | 베타 | 1.22 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | |
| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
@ -138,13 +137,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `IPv6DualStack` | `true` | 베타 | 1.21 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 |
| `LogarithmicScaleDown` | `true` | 베타 | 1.22 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
| `MemoryManager` | `false` | 알파 | 1.21 | 1.21 |
| `MemoryManager` | `true` | 베타 | 1.22 | |
| `MemoryQoS` | `false` | 알파 | 1.22 | |
@ -289,9 +288,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
@ -654,7 +650,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
[토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고
쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다.
[스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
[스토리지 용량](/ko/docs/concepts/storage/storage-capacity/)을 참고한다.
자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다.
이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
@ -698,7 +694,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
모든 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
hugepages 사용을 활성화한다.
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
@ -738,13 +734,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
kubelet과 kube-apiserver를 사용하도록 설정한다.
[확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다.
[확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
[퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
@ -847,7 +843,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
@ -970,7 +966,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
참고한다.
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
파라미터(sysctl)를 지원한다. 자세한 내용은
[sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
[sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
실행이 끝난 후 리소스를 정리하도록
허용한다.

2
content/ko/docs/reference/glossary/extensions.md
View File

@ -15,4 +15,4 @@ tags:
<!--more-->
대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다.
많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다.

Some files were not shown because too many files have changed in this diff Show More