Merge branch 'master' into release-1.12

This commit is contained in:
Tim Fogarty
2018-11-01 14:10:31 -07:00
146 changed files with 4631 additions and 773 deletions
+2
View File
@@ -101,6 +101,7 @@ aliases:
- bradamant3 - bradamant3
- bradtopol - bradtopol
- chenopis - chenopis
- cody-clark
- jaredbhatti - jaredbhatti
- kbarnard10 - kbarnard10
- mistyhacks - mistyhacks
@@ -116,6 +117,7 @@ aliases:
- bradamant3 - bradamant3
- bradtopol - bradtopol
- chenopis - chenopis
- cody-clark
- jaredbhatti - jaredbhatti
- kbarnard10 - kbarnard10
- mistyhacks - mistyhacks
+1
View File
@@ -14,6 +14,7 @@ For more information about contributing to the Kubernetes documentation, see:
* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) * [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/) * [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/) * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
## Running the site locally using Docker ## Running the site locally using Docker
+1 -3
View File
@@ -1,11 +1,9 @@
# Owned by Kubernetes Blog reviewers. # Owned by Kubernetes Blog reviewers.
options: options:
no_parent_owners: true no_parent_owners: false
reviewers: reviewers:
- kbarnard10 - kbarnard10
approvers: approvers:
- bobsky - bobsky
- kbarnard10
- natekartchner - natekartchner
- sarahkconway - sarahkconway
- zacharysarah
@@ -23,7 +23,7 @@ Based on where the Kubernetes community is focusing their development efforts, g
**Basic Concepts** **Basic Concepts**
The are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](https://kubernetes.io/docs/api-reference/v1.6/). There are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](https://kubernetes.io/docs/api-reference/v1.6/).
[![](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s400/rbac1.png)](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s1600/rbac1.png) [![](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s400/rbac1.png)](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s1600/rbac1.png)
@@ -17,7 +17,7 @@ date: 2018-05-29
If you run a Kubernetes environment, chances are youve If you run a Kubernetes environment, chances are youve
customized a Kubernetes configuration — you've copied customized a Kubernetes configuration — you've copied
some API object YAML files and editted them to suit some API object YAML files and edited them to suit
your needs. your needs.
But there are drawbacks to this approach — it can be But there are drawbacks to this approach — it can be
@@ -64,7 +64,7 @@ In this example, the “test” service uses Ambassador annotations to dynamical
![kubeflow-ambassador](/images/blog/2018-06-01-dynamic-ingress-kubernetes/kubeflow-ambassador.png) ![kubeflow-ambassador](/images/blog/2018-06-01-dynamic-ingress-kubernetes/kubeflow-ambassador.png)
With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic to specific backends. For example, when deploying TensorFlow services, Kubeflow creates and and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing. With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic to specific backends. For example, when deploying TensorFlow services, Kubeflow creates and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing.
If youre interested in using Ambassador with Kubeflow, the standard Kubeflow install automatically installs and configures Ambassador. If youre interested in using Ambassador with Kubeflow, the standard Kubeflow install automatically installs and configures Ambassador.
@@ -18,13 +18,6 @@ CoreDNS is a general-purpose, authoritative DNS server that provides a backwards
In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS. In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.
## We appreciate your feedback
We are conducting a survey to evaluate the adoption of CoreDNS as the DNS for Kubernetes's cluster.
If you are currently using CoreDNS inside a Kubernetes cluster, please, [take 5 minutes to provide us some feedback by filling this survey](https://www.surveymonkey.com/r/SKZQSLK).
Thank you, we appreciate your collaboration here.
## Implementation differences ## Implementation differences
In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns` In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
@@ -19,6 +19,8 @@ Intrigued? Let me walk you through how it works.
# Summary # Summary
_**Please note:** this is a cool hack, but is not officially supported in Kubernetes._
First, we need to understand how exactly it works. First, we need to understand how exactly it works.
In short, for all nodes we have prepared the image with the OS, Docker, Kubelet and everything else that you need there. This image with the kernel is building automatically by CI using Dockerfile. End nodes are booting the kernel and OS from this image via the network. In short, for all nodes we have prepared the image with the OS, Docker, Kubelet and everything else that you need there. This image with the kernel is building automatically by CI using Dockerfile. End nodes are booting the kernel and OS from this image via the network.
@@ -365,7 +367,7 @@ Ok, now we have docker image which includes:
OK, now when our docker-image with LTSP-server, kernel, initramfs and squashed rootfs fully prepared we can run the deployment with it. OK, now when our docker-image with LTSP-server, kernel, initramfs and squashed rootfs fully prepared we can run the deployment with it.
We can do that as usual, but one more thing is networking. We can do that as usual, but one more thing is networking.
Unfortunately, we can't use the standard Kubernetes service abstraction for our deployment, because during the boot, our nodes are not part of Kubernetes cluster and they requires ExternalIP, but Kubernetes always enables NAT for ExternalIPs, and there is no way to disable this behavior. Unfortunately, we can't use the standard Kubernetes service abstraction for our deployment, because TFTP can't work behind the NAT. During the boot, our nodes are not part of Kubernetes cluster and they requires ExternalIP, but Kubernetes always enables NAT for ExternalIPs, and there is no way to override this behavior.
For now I have two ways for avoid this: use `hostNetwork: true` or use [pipework](https://github.com/dreamcat4/docker-images/blob/master/pipework/3.%20Examples.md#kubernetes). The second option will also provide you redundancy because, in case of failure, the IP will be moved with the Pod to another node. Unfortunately, pipework is not native and a less secure method. For now I have two ways for avoid this: use `hostNetwork: true` or use [pipework](https://github.com/dreamcat4/docker-images/blob/master/pipework/3.%20Examples.md#kubernetes). The second option will also provide you redundancy because, in case of failure, the IP will be moved with the Pod to another node. Unfortunately, pipework is not native and a less secure method.
If you have some better option for that please let me know. If you have some better option for that please let me know.
@@ -489,8 +491,6 @@ Now you can try to make your own changes.
If you need something more, note that LTSP can be easily changed to meet your needs. If you need something more, note that LTSP can be easily changed to meet your needs.
Feel free to look into the source code and you can find many answers there. Feel free to look into the source code and you can find many answers there.
**UPD:** Many people asking me: Why not simple use CoreOS and Ignition? _**UPD:** Many people asking me: Why not simple use CoreOS and Ignition?_
I can answer. The main feature here is image preparation process not configuration. _I can answer. The main feature here is image preparation process, not configuration. In case with LTSP you have classic Ubuntu system, and everything that can be installed on Ubuntu it can also be written here in the Dockerfile. In case CoreOS you have no so many freedom and you cant easily add custom kernel modules and packages at the build stage of the boot image._
In case with LTSP you have classic Ubuntu system, and everything that can be installed on Ubuntu it can also be written here in the Dockerfile.
In case CoreOS you have no so many freedom and you cant easily add custom kernel modules and packages at the build stage of the boot image.
@@ -170,7 +170,7 @@ The decision to make a scale up is based on pods which remain unscheduled and a
Cluster Autoscaler is available as an add-on with acs-engine. The following link [[15]](https://github.com/Azure/acs-engine/tree/master/examples/addons/cluster-autoscaler) has an example configuration file used to deploy autoscaler with acs-engine. The following link [[8]](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md) provides details on manual step by step way to do the same. Cluster Autoscaler is available as an add-on with acs-engine. The following link [[15]](https://github.com/Azure/acs-engine/tree/master/examples/addons/cluster-autoscaler) has an example configuration file used to deploy autoscaler with acs-engine. The following link [[8]](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md) provides details on manual step by step way to do the same.
In acs-engine case we use the the regular command line to deploy: In acs-engine case we use the regular command line to deploy:
``` ```
acs-engine deploy --subscription-id <subscription id> \ acs-engine deploy --subscription-id <subscription id> \
@@ -0,0 +1,75 @@
---
layout: blog
title: 'Tips for Your First Kubecon Presentation - Part 1'
date: 2018-10-18
---
**Author**: Michael Gasch (VMware)
First of all, let me congratulate you to this outstanding achievement. Speaking at KubeCon, especially if it's your first time, is a tremendous honor and experience. Well done!
<center>{{< tweet 1044345018490662912 >}}</center>
When I was informed that my [KubeCon talk about Kubernetes Resource Management](https://www.youtube.com/watch?v=8-apJyr2gi0) was accepted for KubeCon EU in Denmark (2018), I really could not believe it. By then, the chances to get your talk accepted were around 10% (or less, don't really remember the exact number). There were over a 1,000 submissions just for that KubeCon (recall that we now have **three KubeCon events during the year** - US, EU and Asia region). The popularity of Kubernetes is ever increasing and so is the number of people trying to get a talk accepted. Once again, **outstanding achievement to get your talk in**!
But now comes the tough part - research, write, practice, repeat, go on stage, perform :) Let me tell you that I went through several sleepless nights preparing for my first KubeCon talk. The day of the presentation, until I got on stage, was a mixture of every emotion I could have possibly gone through. Even though I had presented uncountable times before, including large industry conferences, KubeCon was very different. Different because it was the first time everything was recorded (including the presenter on stage) and I did not really know the audience, or more precisely: I was assuming everyone in the room is a Kubernetes expert and that my presentation not only had to be entertaining but also technically deep and 100% accurate. It's not seldom that maintainers and SIG (Special Interest Group) leads are in the room as well.
Another challenge for me was squeezing a topic, that can easily fill a full-day workshop, into a 35min presentation (including Q&A). Before KubeCon, I was used to giving breakouts which were typically 60 minutes long. This doesn't say anything about the quality of the presentation but I knew how many slides I can squeeze into 60 minutes, covering important details but not killing people with "Death by PowerPoint".
So I learned a lot going through this endless cycle of preparation, practicing, these doubts of failing and time pressure finishing your deck, and of course giving the talk. When I left Copenhagen, I took some notes based on my speaker experience during the flight, which my friend [Bjoern](https://twitter.com/bbrundert) encouraged me to share. Not all of them might apply to you, but I still hope some of them are useful for your first KubeCon talk.
## Submitting a Good Talk
Some of you might read these lines even though you did not submit a talk or it wasn't accepted. I found these resources (not specifically targeted at KubeCon) for writing a good proposal very useful:
- [How to write with Style](http://www.novelr.com/2008/08/16/vonnegut-how-to-write-with-style)
- [Talk Framework](https://docs.google.com/document/d/16llwMgq38wIt19Oj-TrunrPsfczrCNgvIqioslcdb6Q/edit) by the incredible [goinggodotnet](https://twitter.com/goinggodotnet)
- [Lachies 7 step guide to writing a winning tech conference CFP](https://medium.com/@LachlanEvenson/lachies-7-step-guide-to-writing-a-winning-tech-conference-cfp-4fa36a0d2672)
Believe it or not, mine went through several reviews by Justin Garrison, Liz Rice, Bill Kennedy, Emad Benjamin and Kelsey Hightower (yes, THE Kelsey Hightower)! Some of them didn't know me before, they just live by our community values to grow newcomers and thus drive this great community forward every day.
I think, without their feedback my proposal wouldn't have been on point to be selected. Their feedback was often direct and required me to completely change the first revisions. But they were right and their feedback was useful to stay within the character limit while still standing out with the proposal.
Feel free to reach out for professional and/or experienced speakers. They know this stuff. And I was surprised by the support and help offered. Many had their DMs in Twitter open, so ask for help and you will be helped :) Besides Twitter, related forums to ask for assistance might be [Discuss](https://discuss.kubernetes.io/) and [Reddit](https://www.reddit.com/r/kubernetes/).
## Preparing for your Presentation
**Tip #1 - Appreciate that you were selected** and don't be upset about the slot your presentation was scheduled in. For example, my talk was put as second last presentation of final KubeCon day (Friday). I was like, who's going to stay there and not catch his/her flight or hang out and relax after this crazy week? The session stats, where speakers can see who signed up, were slowly increasing until the week of KubeCon. I think at the beginning of the week it showed ~80 people interested in my session (there is no mandatory sign-up). I was so happy, especially since there were some interesting talks running at the same time as my presentation.
Without spoiling (see below), the KubeCon community and attendees fully leverage the time and effort they've put into traveling to KubeCon. Rest assured that even if you have the last presentation at KubeCon, people will show up!
**Tip #2 - Study the Masters on [Youtube](https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA/playlists)**. Get some inspirations from great speakers (some of them already mentioned above) and top rated sessions of previous KubeCons. Observe how they present and interact with the audience, while still keeping the tough timing throughout the presentation.
**Tip #3 - Find reviewers**. Having experienced or professional speakers review your slides is super critical. Not only to check for language/translation (see below) but also to improve the flow of your presentation and get feedback on whether the content is logically structured and not too dense (too many slides, timing). They will help you to leave out less important information while also making the presentation fit for your audience (not everyone has the level of knowledge as you in your specific area).
**Tip #4 - Language barriers**. Nobody is perfect and the community encourages diversity. This makes us all better and is what I probably like the most about the Kubernetes community. However, make sure that the audience understands the message of your talk. For non-native speakers, it can be really hard to present in English (e.g. at the US/EU conferences), especially if you're not used to it. Add to that the tension during the talk and it can become really hard for the audience to follow.
I am not saying that everyone has to present in perfect business English. Nobody expects that, let me be very clear. But if you feel that this could be an issue for you, reach out for help. Reviewers can help fix grammar and wording in your slide deck. Practicing and recording yourself (see below) are helpful to reflect yourself. The slides should reflect your message so people can read along if they lost you. Simple, less busy slides are definitely recommended. Make sure to add speaker notes to your presentation. Not only does this help with getting better every time you run through your presentation (memory effect and the flow). It also serves as a safety net when you think language will definitely be an issue, or when you're suddenly completely lost during the presentation on stage.
**Tip #5 - Study the Speaker Guidelines**. Nothing to add here, take them seriously and reach out to the (fantastic) speaker support if you have questions. Also submit your presentation in time (plan ahead accordingly) to not risk any trouble with the committee.
**Tip #6 - Practice like never before**. Practicing is probably the most important tip I can give you. I don't know how many times I practiced my talk, e.g. at home but also at some local Meetups to get some early feedback. First I was shocked with timing. Even though I had my deck down to 40min in my dry runs at home, at the Meetup I completely run out of time (50min). I was shocked, as I didn't know what to leave out.
The feedback from these sessions helped me to trim down content as it helped me to understand what to leave out/shorten. Keep in mind to also leave room for questions as a best practice (requirement?) by the speaker guidelines.
**Tip #7 - The Demo Gods are not always with you**. Demos can and will go wrong. Not just because of the typical suspect like slow WiFi, etc. I heard horror stories about expired certificates, daylight saving times (for those traveling through time zones on their way to KubeCon) affecting deployments, the content of a variable in your BASH script changing (e.g. when curling stuff from the web), keyboards breaking (Mac lovers, can you believe that?), hard disks crashing (even the backup disk not working), and so on.
Never ever rely on the demo gods, especially when you're not Kelsey Hightower :) Take [video recordings](https://asciinema.org/) of your demos so you not only have a backup when the live demo breaks. But also in case you're afraid of running out of time. In order to avoid the primary and backup disks crashing (yes, it happened at that KubeCon I was told), store a copy at your trusted cloud provider.
**Tip #8 - The right Tools for the job**. Sometimes you want to highlight something on your slide. This has two potentially issues. First, you have to constantly turn away from the audience which does not necessarily look good (if you can avoid it). Second, it might not always work depending on the (laser) pointer and room equipment (light, background).
[This presenter](https://www.logitech.com/en-us/product/spotlight-presentation-remote) from Logitech has really served me well. It has several useful features, the "Spotlight" (that's why the name) being my favorite feature. You'll never want to go back.
**Tip #9 - Being recorded**. I am not sure if you can opt-out from being recorded (please check with speaker support on the latest guidelines here) if you don't want to appear on Youtube for the rest of your life. But audio definitely will be recorded so chose your words (jokes) wisely. Again, practicing and reviewing helps. If you're ok with being recorded, at least think about which shirt (logos and "art") you want to be remembered by the internet ;)
**Tip #10 - Social media**. Social media is great for promoting your session and you should definitely send out reminders on various channels for your presentation. Something that is missing almost every time in the presentation templates (if you want to use them) is placeholders for your social media account and, more importantly, for your session ID. Even if the conference does not use session IDs externally (in the schedule builder), you might still want to add a handle to every slide so people can refer to your presentation (or particular slide) on social media with a hashtag that you then can search for feedback, questions, etc.
**Tip #11 - Be yourself**. Be authentic and don't try to sound super smart or funny (unless you are ;)). Seriously. Just be yourself and people will love you. Authenticity is key for a great presentation and the audience will smell when you try to fool them. It also makes practicing and the live performance easier as you don't have to pay attention on acting like somebody else.
From a content perspective make sure that **you** own and develop the content and you did not copy and paste like crazy from the Kubernetes docs or other presentations. It's absolutely ok to reference other sources, but please give them credit. Again, the audience will smell if you make things up. You should know what you're speaking about (not saying that you have to be an expert, but experience is what makes your talk unique). The final proof is during Q&A and KubeCon is a sharp audience ;)
**Tip #12 - Changes to the proposal**. The committee, based on your proposal description and details, might change the audience level. For example, I put my talk in as intermediate, but it was changed to all skill levels. This is not bad per se. Just watch out for changes and adapt your presentation accordingly or reach out to speaker support. If you were not expecting beginners or architects in your talk (because you had chosen another skill level and target group), you might lose parts of your audience. This could also negatively affect your session feedback/scores.
## Wrapping up
I hope some of these tips are already useful and will help you getting started to work on your presentation. In the next post we are going to cover speaker tips when you are finally at the KubeCon event.
@@ -0,0 +1,55 @@
---
layout: blog
title: 'Tips for Your First Kubecon Presentation - Part 2'
date: 2018-10-26
---
**Author**: Michael Gasch (VMware)
Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation---part-1/).
## The Day before the Show
**Tip #13 - Get enough sleep**. I don't know about you, but when I don't get enough sleep (especially when beer is in the game), the next day my brain power is around 80% at best. It's very easy to get distracted at KubeCon (in a positive sense). "Let's have dinner tonight and chat about XYZ". Get some food, beer or wine because you're so excited and all the good resolutions you had set for the day before your presentation are forgotten :)
OK, I'm slightly exaggerating here. But don't underestimate the dynamics of this conference, the amazing people you meet, the inspiring talks and of course the conference party. Be disciplined, at least that one day. There's enough time to party after your great presentation!
**Tip #14 - A final dry-run**. Usually, I do a final dry-run of my presentation the day before the talk. This helps me to recall the first few sentences I want to say so I keep the flow no matter what happens when the red recording light goes on. Especially when your talk is later during the conference, there's so much new stuff your brain has to digest which could "overwrite" the very important parts of your presentation. I think you know what I mean. So, if you're like me, a final dry-run is never a bad idea (also to check equipment, demos, etc.).
**Tip #15 - Promote your session, again**. Send out a final reminder on your social media channels so your followers (and KubeCon attendees) will recall to attend your session (again, KubeCon is busy and it's hard to keep up with all the talks you wanted to attend). I was surprised to see my attendee list jumping from ~80 at the beginning of the week to >300 the day before the talk. The number kept rising even an hour before going on stage. So don't worry about the stats too early.
**Tip #16 - Ask your idols to attend**. [Steve Wong](https://twitter.com/cantbewong), a colleague of mine who I really admire for his knowledge and passion, gave me a great advise. Reach out to the people you always wanted to attend your talk and kindly ask them to come along.
So I texted the one and only [Tim Hockin](https://twitter.com/thockin?lang=de). Even though these well-respected community leaders are super busy and thus usually cannot attend many talks during the conference, the worst thing that can happen is that they cannot show up and will let you know. (see the end of this post to find out whether or not I was lucky :))
## The show is on!
Your day has come and it doesn't make **any** sense to make big changes to your presentation now! Actually, that's a very bad idea unless you're an expert and your heartbeat at rest is around 40 BPM. (But even then many things can go horribly wrong).
So, without further ado, here are my final tips for you.
**Tip #17 - Arrive ahead of time**. Set an alert (or two) to not miss your presentation, e.g. because somebody caught you on the way to the room or you got a call/have been pulled in a meeting. It's a good idea to find out were your room is at least some hours before your talk. These conference buildings can be very large. Also look for last minute schedule (time/room) changes, just because you never know...
**Tip #18 - Ask a friend to take photos**. My dear colleague [Bjoern](https://twitter.com/bbrundert), without me asking for it, took a lot of pictures and watched the audience during the talk. This was really helpful, not just because I now have some nice shots that will always remind me of this great day. He also gave me honest feedback, e.g. what people said, whether they liked it or what I could have done better.
**Tip #19 - Restroom**. If you're like me, when I'm nervous I could run every 15 minutes. The last thing you want is that you are fully cabled (microphone), everything is set up and two minutes before your presentation you feel like "oh oh"...nothing more to say here ;)
**Tip #20 - The audience**. I had many examples and references from other Kubernetes users (and their postmortem stories) in my talk. So I tried to give them credit and actually some of them were in the room and really liked that I did so. It gave them (and hopefully the rest of the audience as well) the feeling that I did not invent the wheel and we are all in the same boat. Also feel free to ask some questions in the beginning, e.g. to get a better feeling about who is attending your talk, or who would consider himself an expert in the area of what you are talking about, etc.
**Tip #21 - Repeat questions. Always**. Because of the time constraints, questions should be asked at the end of your presentation (unless you are giving a community meeting or panel of course). Always (always!) repeat the questions at the end. Sometimes people will not use the microphone. This is not only hard for the people in the back, but also it won't be captured on the recording. I am sure you also had that moment watching a recording and not getting what is being asked/discussed because the question was not captured.
**Tip #22 - Feedback**. Don't forget to ask the audience to fill out the survey. They're not always enforced/mandatory during conferences (especially not at KubeCon), so it's easy to forget to give the speaker feedback. Feedback is super critical (also for the committee) as sometimes people won't directly tell you but rather write their thoughts. Also, you might want to block your calendar to leave some time after the presentation for follow-up questions, so you are not in the hurry to catch your next meeting/session.
**Tip #23 - Invite your audience**. No, I don't mean to throw a round of beer for everyone attending your talk (I mean, you could). But you might let them know, at the end of your presentation, that you would like to hang out, have dinner, etc. A great opportunity to reflect and geek out with like-minded friends.
**Final Tip - Your Voice matters**. Don't underestimate the power of giving a talk at a conference. In my case I was lucky that the Zalando crew was in the room and took this talk as an opportunity for an ad hoc meeting after the conference. This drove an important performance fix forward, which eventually was [merged](https://github.com/kubernetes/kubernetes/pull/63437) (kudos to the Zalando team again!).
Embrace the opportunity to give a talk at a conference, take it serious, be professional and make the best use of your time. But I'm sure I don't have to tell you that ;)
## Now it's on you :)
I hope some of these tips are useful for you as well. And I wish you all the best for your upcoming talk!!! Believing in and being yourself is key to success. And perhaps your Kubernetes idol is in the room and has some nice words for you after your presentation!
Besides my fantastic reviewers and the speaker support team already mentioned above, I also would like to thank the people who supported me along this KubeCon journey: Bjoern, Timo, Emad and Steve!
{{< tweet 992409364467200000 >}}
+1 -3
View File
@@ -1,10 +1,8 @@
# Owned by Kubernetes Blog reviewers. # Owned by Kubernetes Blog reviewers.
options: options:
no_parent_owners: true no_parent_owners: false
reviewers: reviewers:
- alexcontini - alexcontini
approvers: approvers:
- alexcontini - alexcontini
- kbarnard10
- sarahkconway - sarahkconway
- zacharysarah
@@ -0,0 +1 @@
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>

After

Width:  |  Height:  |  Size: 4.3 KiB

+1 -1
View File
@@ -5,7 +5,7 @@ linkTitle: IBM
case_study_styles: true case_study_styles: true
cid: caseStudies cid: caseStudies
css: /css/style_case_studies.css css: /css/style_case_studies.css
logo: ibm_featured_logo.png logo: ibm_featured_logo.svg
featured: true featured: true
weight: 2 weight: 2
quote: > quote: >
@@ -18,7 +18,6 @@ Here's the architecture of a Kubernetes cluster without the cloud controller man
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -18,7 +18,6 @@ cloud provider).
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -18,7 +18,6 @@ architecture design doc for more details.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -14,7 +14,6 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -12,7 +12,6 @@ manually through `easyrsa`, `openssl` or `cfssl`.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -9,7 +9,6 @@ This page explains how to manage Kubernetes running on a specific
cloud provider. cloud provider.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
### kubeadm ### kubeadm
@@ -14,7 +14,6 @@ External garbage collection tools are not recommended as these tools can potenti
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -42,7 +41,7 @@ Containers that are not managed by kubelet are not subject to container garbage
Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags : Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags :
1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection. 1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
Default is 90%. Default is 85%.
2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts 2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
to free. Default is 80%. to free. Default is 80%.
@@ -15,7 +15,6 @@ However, the native functionality provided by a container engine or runtime is u
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -14,7 +14,6 @@ You've deployed your application and exposed it via a service. Now what? Kuberne
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -18,7 +18,6 @@ default. There are 4 distinct networking problems to solve:
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -152,6 +151,18 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu
[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [OpenContrail](http://www.opencontrail.org), is a truly open, multi-cloud network virtualization and policy management platform. Contrail / OpenContrail is integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provides different isolation modes for virtual machines, containers/pods and bare metal workloads. [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [OpenContrail](http://www.opencontrail.org), is a truly open, multi-cloud network virtualization and policy management platform. Contrail / OpenContrail is integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provides different isolation modes for virtual machines, containers/pods and bare metal workloads.
### DANM
[DANM](https://github.com/nokia/danm) is a networking solution for telco workloads running in a Kubernetes cluster. It's built up from the following components:
* A CNI plugin capable of provisioning IPVLAN interfaces with advanced features
* An in-built IPAM module with the capability of managing multiple, cluster-wide, discontinuous L3 networks and provide a dynamic, static, or no IP allocation scheme on-demand
* A CNI metaplugin capable of attaching multiple network interfaces to a container, either through its own CNI, or through delegating the job to any of the popular CNI solution like SRI-OV, or Flannel in parallel
* A Kubernetes controller capable of centrally managing both VxLAN and VLAN interfaces of all Kubernetes hosts
* Another Kubernetes controller extending Kubernetes' Service-based service discovery concept to work over all network interfaces of a Pod
With this toolset DANM is able to provide multiple separated network interfaces, the possibility to use different networking back ends and advanced IPAM features for the pods.
### Flannel ### Flannel
[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay [Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
@@ -277,11 +288,6 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
or stand-alone. In either version, it doesn't require any configuration or extra code or stand-alone. In either version, it doesn't require any configuration or extra code
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
### 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.
{{% /capture %}} {{% /capture %}}
{{% capture whatsnext %}} {{% capture whatsnext %}}
@@ -8,7 +8,6 @@ content_template: templates/concept
weight: 30 weight: 30
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -10,7 +10,6 @@ feature:
weight: 50 weight: 50
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -8,7 +8,6 @@ content_template: templates/concept
weight: 40 weight: 40
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
@@ -13,7 +13,6 @@ This page describes the resources available to Containers in the Container envir
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -63,5 +62,3 @@ if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addon
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}} {{% /capture %}}
@@ -14,7 +14,6 @@ to run code triggered by events during their management lifecycle.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -122,5 +121,3 @@ Events:
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}} {{% /capture %}}
@@ -15,7 +15,6 @@ The `image` property of a container supports the same syntax as the `docker` com
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -50,7 +49,7 @@ These commands rely on and are implemented purely on the Docker CLI. You will ne
If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh. If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatability, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes. For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
## Using a Private Registry ## Using a Private Registry
@@ -140,7 +140,6 @@ This page describes the RuntimeClass resource and runtime selection mechanism.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -8,7 +8,6 @@ content_template: templates/concept
weight: 10 weight: 10
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -22,7 +22,6 @@ Kubernetes itself is decomposed into multiple components, which interact through
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -26,7 +26,6 @@ We'll eventually index and reverse-index labels for efficient queries and watche
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -17,7 +17,6 @@ See the [identifiers design doc](https://git.k8s.io/community/contributors/desig
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -15,7 +15,6 @@ These virtual clusters are called namespaces.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -16,7 +16,6 @@ updates.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -15,7 +15,6 @@ Resource quotas are a tool for administrators to address this concern.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -8,7 +8,6 @@ content_template: templates/concept
weight: 30 weight: 30
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -375,4 +374,3 @@ the [Federated Services User Guide](/docs/concepts/cluster-administration/federa
for further information. for further information.
{{% /capture %}} {{% /capture %}}
@@ -11,7 +11,6 @@ content_template: templates/concept
weight: 10 weight: 10
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -940,7 +939,7 @@ Kubernetes supports SCTP as a `protocol` value in `Service`, `Endpoint`, `Networ
The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a `Pod`. The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a `Pod`.
NAT for multihomed SCTP assoications requires special logic in the corresponding kernel modules. NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
#### Service with type=LoadBalancer #### Service with type=LoadBalancer
@@ -961,4 +960,3 @@ The kube-proxy does not support the management of SCTP associations when it is i
Read [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/). Read [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/).
{{% /capture %}} {{% /capture %}}
@@ -21,7 +21,6 @@ automatically provisions storage when it is requested by users.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -132,5 +131,3 @@ Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
{{% /capture %}} {{% /capture %}}
@@ -20,7 +20,6 @@ This document describes the current state of `PersistentVolumes` in Kubernetes.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -17,7 +17,6 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -15,7 +15,6 @@ This document describes the current state of `VolumeSnapshots` in Kubernetes. Fa
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -22,7 +22,6 @@ Familiarity with [Pods](/docs/user-guide/pods) is suggested.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -1302,5 +1301,3 @@ $ sudo systemctl restart docker
{{% capture whatsnext %}} {{% capture whatsnext %}}
* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). * Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
{{% /capture %}} {{% /capture %}}
@@ -22,7 +22,6 @@ For instructions on creating and working with cron jobs, and for an example of a
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node. - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
- running a logs collection daemon on every node, such as `fluentd` or `logstash`. - running a logs collection daemon on every node, such as `fluentd` or `logstash`.
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter]( - running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent. https://github.com/prometheus/node_exporter), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent.
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon. In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
A more complex setup might use multiple DaemonSets for a single type of daemon, but with A more complex setup might use multiple DaemonSets for a single type of daemon, but with
@@ -29,7 +29,6 @@ different flags and/or different memory and cpu requests for different hardware
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -107,7 +107,7 @@ Notice how the values in each field correspond to the values in the Deployment s
* The number of up-to-date replicas is 0 according to the `.status.updatedReplicas` field. * The number of up-to-date replicas is 0 according to the `.status.updatedReplicas` field.
* The number of available replicas is 0 according to the `.status.availableReplicas` field. * The number of available replicas is 0 according to the `.status.availableReplicas` field.
To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. This command returns the following output: To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. This command returns the following output:
```shell ```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
@@ -171,21 +171,21 @@ Suppose that you now want to update the nginx Pods to use the `nginx:1.9.1` imag
instead of the `nginx:1.7.9` image. instead of the `nginx:1.7.9` image.
```shell ```shell
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record $ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record
deployment.apps/nginx-deployment image updated deployment.apps/nginx-deployment image updated
``` ```
Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`: Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
```shell ```shell
$ kubectl edit deployment/nginx-deployment $ kubectl edit deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment edited deployment.apps/nginx-deployment edited
``` ```
To see the rollout status, run: To see the rollout status, run:
```shell ```shell
$ kubectl rollout status deployment/nginx-deployment $ kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out deployment.apps/nginx-deployment successfully rolled out
``` ```
@@ -337,48 +337,45 @@ rolled back.
Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
```shell ```shell
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91 $ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
deployment.apps/nginx-deployment image updated deployment.apps/nginx-deployment image updated
``` ```
The rollout will be stuck. The rollout will be stuck.
```shell ```shell
$ kubectl rollout status deployments nginx-deployment $ kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
``` ```
Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts, Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts,
[read more here](#deployment-status). [read more here](#deployment-status).
You will also see that both the number of old replicas (nginx-deployment-1564180365 and You will see that the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) is 2, and new replicas (nginx-deployment-3066724191) is 1.
nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2.
```shell ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT READY AGE NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 2 2 2 25s nginx-deployment-1564180365 3 3 3 25s
nginx-deployment-2035384211 0 0 0 36s nginx-deployment-2035384211 0 0 0 36s
nginx-deployment-3066724191 2 2 0 6s nginx-deployment-3066724191 1 1 0 6s
``` ```
Looking at the Pods created, you will see that the 2 Pods created by new ReplicaSet are stuck in an image pull loop. Looking at the Pods created, you will see that 1 Pod created by new ReplicaSet is stuck in an image pull loop.
```shell ```shell
$ kubectl get pods $ kubectl get pods
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
nginx-deployment-1564180365-hysrc 1/1 Running 0 25s
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
``` ```
{{< note >}} {{< note >}}
**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new **Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
Kubernetes by default sets the value to 1 and `.spec.replicas` to 1 so if you haven't cared about setting those Kubernetes by default sets the value to 25%.
parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
version.
{{< /note >}} {{< /note >}}
```shell ```shell
@@ -388,12 +385,27 @@ Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx Labels: app=nginx
Selector: app=nginx Selector: app=nginx
Replicas: 2 updated | 3 total | 2 available | 2 unavailable Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType: RollingUpdate StrategyType: RollingUpdate
MinReadySeconds: 0 MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge RollingUpdateStrategy: 25% max unavailable, 25% max surge
OldReplicaSets: nginx-deployment-1564180365 (2/2 replicas created) Pod Template:
NewReplicaSet: nginx-deployment-3066724191 (2/2 replicas created) Labels: app=nginx
Containers:
nginx:
Image: nginx:1.91
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
Events: Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ ------- --------- -------- ----- ---- ------------- -------- ------ -------
@@ -401,11 +413,10 @@ Events:
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-1564180365 to 2
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
``` ```
To fix this, you need to rollback to a previous revision of Deployment that is stable. To fix this, you need to rollback to a previous revision of Deployment that is stable.
@@ -415,27 +426,27 @@ To fix this, you need to rollback to a previous revision of Deployment that is s
First, check the revisions of this deployment: First, check the revisions of this deployment:
```shell ```shell
$ kubectl rollout history deployment/nginx-deployment $ kubectl rollout history deployment.v1.apps/nginx-deployment
deployments "nginx-deployment" deployments "nginx-deployment"
REVISION CHANGE-CAUSE REVISION CHANGE-CAUSE
1 kubectl create --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true 1 kubectl create --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
``` ```
`CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You could specify the`CHANGE-CAUSE` message by: `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You could specify the`CHANGE-CAUSE` message by:
* Annotating the Deployment with `kubectl annotate deploy nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
* Append the `--record` flag to save the `kubectl` command that is making changes to the resource. * Append the `--record` flag to save the `kubectl` command that is making changes to the resource.
* Manually editing the manifest of the resource. * Manually editing the manifest of the resource.
To further see the details of each revision, run: To further see the details of each revision, run:
```shell ```shell
$ kubectl rollout history deployment/nginx-deployment --revision=2 $ kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2 deployments "nginx-deployment" revision 2
Labels: app=nginx Labels: app=nginx
pod-template-hash=1159050644 pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
Containers: Containers:
nginx: nginx:
Image: nginx:1.9.1 Image: nginx:1.9.1
@@ -452,14 +463,14 @@ deployments "nginx-deployment" revision 2
Now you've decided to undo the current rollout and rollback to the previous revision: Now you've decided to undo the current rollout and rollback to the previous revision:
```shell ```shell
$ kubectl rollout undo deployment/nginx-deployment $ kubectl rollout undo deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment deployment.apps/nginx-deployment
``` ```
Alternatively, you can rollback to a specific revision by specify that in `--to-revision`: Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
```shell ```shell
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2 $ kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
deployment.apps/nginx-deployment deployment.apps/nginx-deployment
``` ```
@@ -479,7 +490,7 @@ Namespace: default
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4 Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
Selector: app=nginx Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate StrategyType: RollingUpdate
@@ -522,7 +533,7 @@ Events:
You can scale a Deployment by using the following command: You can scale a Deployment by using the following command:
```shell ```shell
$ kubectl scale deployment nginx-deployment --replicas=10 $ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
deployment.apps/nginx-deployment scaled deployment.apps/nginx-deployment scaled
``` ```
@@ -531,7 +542,7 @@ in your cluster, you can setup an autoscaler for your Deployment and choose the
Pods you want to run based on the CPU utilization of your existing Pods. Pods you want to run based on the CPU utilization of your existing Pods.
```shell ```shell
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 $ kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment.apps/nginx-deployment scaled deployment.apps/nginx-deployment scaled
``` ```
@@ -553,7 +564,7 @@ nginx-deployment 10 10 10 10 50s
You update to a new image which happens to be unresolvable from inside the cluster. You update to a new image which happens to be unresolvable from inside the cluster.
```shell ```shell
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag $ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
deployment.apps/nginx-deployment image updated deployment.apps/nginx-deployment image updated
``` ```
@@ -607,21 +618,21 @@ nginx-2142116321 3 3 3 1m
Pause by running the following command: Pause by running the following command:
```shell ```shell
$ kubectl rollout pause deployment/nginx-deployment $ kubectl rollout pause deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment paused deployment.apps/nginx-deployment paused
``` ```
Then update the image of the Deployment: Then update the image of the Deployment:
```shell ```shell
$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1 $ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated deployment.apps/nginx-deployment image updated
``` ```
Notice that no new rollout started: Notice that no new rollout started:
```shell ```shell
$ kubectl rollout history deploy/nginx-deployment $ kubectl rollout history deployment.v1.apps/nginx-deployment
deployments "nginx" deployments "nginx"
REVISION CHANGE-CAUSE REVISION CHANGE-CAUSE
1 <none> 1 <none>
@@ -634,7 +645,7 @@ nginx-2142116321 3 3 3 2m
You can make as many updates as you wish, for example, update the resources that will be used: You can make as many updates as you wish, for example, update the resources that will be used:
```shell ```shell
$ kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi $ kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
deployment.apps/nginx-deployment resource requirements updated deployment.apps/nginx-deployment resource requirements updated
``` ```
@@ -644,7 +655,7 @@ the Deployment will not have any effect as long as the Deployment is paused.
Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates: Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
```shell ```shell
$ kubectl rollout resume deploy/nginx-deployment $ kubectl rollout resume deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment resumed deployment.apps/nginx-deployment resumed
$ kubectl get rs -w $ kubectl get rs -w
NAME DESIRED CURRENT READY AGE NAME DESIRED CURRENT READY AGE
@@ -702,7 +713,7 @@ You can check if a Deployment has completed by using `kubectl rollout status`. I
successfully, `kubectl rollout status` returns a zero exit code. successfully, `kubectl rollout status` returns a zero exit code.
```shell ```shell
$ kubectl rollout status deploy/nginx-deployment $ kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available... Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out deployment.apps/nginx-deployment successfully rolled out
$ echo $? $ echo $?
@@ -730,7 +741,7 @@ The following `kubectl` command sets the spec with `progressDeadlineSeconds` to
lack of progress for a Deployment after 10 minutes: lack of progress for a Deployment after 10 minutes:
```shell ```shell
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' $ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
deployment.apps/nginx-deployment patched deployment.apps/nginx-deployment patched
``` ```
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
@@ -835,7 +846,7 @@ You can check if a Deployment has failed to progress by using `kubectl rollout s
returns a non-zero exit code if the Deployment has exceeded the progression deadline. returns a non-zero exit code if the Deployment has exceeded the progression deadline.
```shell ```shell
$ kubectl rollout status deploy/nginx-deployment $ kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline error: deployment "nginx" exceeded its progress deadline
$ echo $? $ echo $?
@@ -26,7 +26,6 @@ A Job can also be used to run multiple pods in parallel.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -24,7 +24,6 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -18,7 +18,6 @@ cluster actions, like upgrading and autoscaling clusters.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -266,6 +265,3 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
{{% /capture %}} {{% /capture %}}
@@ -12,7 +12,6 @@ Containers that run before app Containers and can contain utilities or setup
scripts not present in an app image. scripts not present in an app image.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
This feature has exited beta in 1.6. Init Containers can be specified in the PodSpec This feature has exited beta in 1.6. Init Containers can be specified in the PodSpec
alongside the app `containers` array. The beta annotation value will still be respected alongside the app `containers` array. The beta annotation value will still be respected
@@ -329,6 +328,3 @@ is removed, requiring a conversion from the deprecated annotations to the
* [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) * [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
{{% /capture %}} {{% /capture %}}
@@ -10,7 +10,6 @@ weight: 10
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model. This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
## Understanding Pods ## Understanding Pods
@@ -104,5 +103,3 @@ Rather than specifying the current desired state of all replicas, pod templates
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* Other Pod Topics * Other Pod Topics
{{% /capture %}} {{% /capture %}}
@@ -12,7 +12,6 @@ managed in Kubernetes.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -12,7 +12,6 @@ certain information into pods at creation time. The information can include
secrets, volumes, volume mounts, and environment variables. secrets, volumes, volume mounts, and environment variables.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
## Understanding Pod Presets ## Understanding Pod Presets
@@ -83,5 +82,3 @@ In order to use Pod Presets in your cluster you must ensure the following:
* [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) * [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
{{% /capture %}} {{% /capture %}}
+1 -1
View File
@@ -257,7 +257,7 @@ to the Github UI.
``` ```
4. Check out the remote branch. This command will fail if you already have a 4. Check out the remote branch. This command will fail if you already have a
local branch with the sane name. local branch with the same name.
```bash ```bash
git checkout <branch-from-PR> git checkout <branch-from-PR>
+1 -2
View File
@@ -20,7 +20,6 @@ We encourage you to add new [localizations](https://blog.mozilla.org/l10n/2011/
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -100,7 +99,7 @@ Provide guidance to localization contributors in the localized `README-**.md` fi
- A point of contact for the localization project - A point of contact for the localization project
- Any information specific to the localization - Any information specific to the localization
After you create the localized README, add a link to the file from the main English file, [`README.md`] and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. After you create the localized README, add a link to the file from the main English file, [`README.md`'s Localizing Kubernetes Documentation] and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact.
## Translating documents ## Translating documents
+2 -2
View File
@@ -154,8 +154,8 @@ process guidelines and information about deadlines.
### Sign the CLA ### Sign the CLA
Before you can contribute code or documentation to Kubernetes, you **must** read Before you can contribute code or documentation to Kubernetes, you **must** read
the [Contributor guide](/docs/community/guide/) and the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and
[sign the Contributor License Agreement (CLA)](/docs/community/guide/#sign-the-cla). [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Don't worry -- this doesn't take long! Don't worry -- this doesn't take long!
### Find something to work on ### Find something to work on
@@ -4,7 +4,6 @@ content_template: templates/concept
weight: 40 weight: 40
--- ---
{{< toc >}}
{{% capture overview %}} {{% capture overview %}}
@@ -137,4 +136,3 @@ The `SASS` source of the stylesheets for this site is stored below `src/sass` an
* [Style guide](/docs/contribute/style/style-guide) * [Style guide](/docs/contribute/style/style-guide)
{{% /capture %}} {{% /capture %}}
@@ -23,7 +23,6 @@ template to use for a new topic, start with the
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -221,4 +220,3 @@ An example of a published topic that uses the tutorial template is
- Learn about [content organization](/docs/contribute/style/content-organization/) - Learn about [content organization](/docs/contribute/style/content-organization/)
{{% /capture %}} {{% /capture %}}
+1 -1
View File
@@ -8,7 +8,7 @@ cid: userJourneys
css: /css/style_user_journeys.css css: /css/style_user_journeys.css
js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
display_browse_numbers: true display_browse_numbers: true
linkTitle: Documentation linkTitle: "Home"
main_menu: true main_menu: true
weight: 10 weight: 10
menu: menu:
@@ -33,9 +33,9 @@ This page describes how to use Admission Webhooks and Initializers.
Admission webhooks are HTTP callbacks that receive admission requests and do Admission webhooks are HTTP callbacks that receive admission requests and do
something with them. You can define two types of admission webhooks, something with them. You can define two types of admission webhooks,
[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9) [validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
and and
[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9). [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
With validating admission Webhooks, you may reject requests to enforce custom With validating admission Webhooks, you may reject requests to enforce custom
admission policies. With mutating admission Webhooks, you may change requests to admission policies. With mutating admission Webhooks, you may change requests to
enforce custom defaults. enforce custom defaults.
@@ -898,7 +898,8 @@ The RBAC authorizer will attempt to authorize requests first. If it denies an AP
the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC
or ABAC policies is allowed. or ABAC policies is allowed.
When run with a log level of 2 or higher (`--v=2`), you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`). When the apiserver is run with a log level of 5 or higher for the RBAC component (`--vmodule=rbac*=5` or `--v=5`),
you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`).
You can use that information to determine which roles need to be granted to which users, groups, or service accounts. You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages
in the server logs, you can remove the ABAC authorizer. in the server logs, you can remove the ABAC authorizer.
@@ -38,7 +38,7 @@ different Kubernetes components.
| `APIListChunking` | `true` | Beta | 1.9 | | | `APIListChunking` | `true` | Beta | 1.9 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | |
| `AppArmor` | `true` | Beta | 1.4 | | | `AppArmor` | `true` | Beta | 1.4 | |
| `AttachVolumeLimit` | `false` | Alpha | 1.11 | | | `AttachVolumeLimit` | `true` | Alpha | 1.11 | |
| `BlockVolume` | `false` | Alpha | 1.9 | | | `BlockVolume` | `false` | Alpha | 1.9 | |
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
| `CPUManager` | `true` | Beta | 1.10 | | | `CPUManager` | `true` | Beta | 1.10 | |
@@ -213,7 +213,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
When the `Initializers` admission controller is enabled, this feature is automatically enabled. When the `Initializers` admission controller is enabled, this feature is automatically enabled.
- `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file. - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details. See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.
- `KubletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi). to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). - `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
- `MountContainers`: Enable using utility containers on host as the volume mounter. - `MountContainers`: Enable using utility containers on host as the volume mounter.
@@ -0,0 +1,20 @@
---
title: Aggregation Layer
id: aggregation-layer
date: 2018-10-08
full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
short_description: >
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
aka:
tags:
- architecture
- extension
- operation
---
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
<!--more-->
When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
@@ -23,7 +23,7 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete
Were extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers. Were extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE.md). To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md).
You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure. You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.
@@ -282,7 +282,7 @@ kubectl api-resources --api-group=extensions # All resources in the "extensions"
### Formatting output ### Formatting output
To output details to your terminal window in a specific format, you can add either the `-o` or `-output` flags to a supported `kubectl` command. To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
Output format | Description Output format | Description
--------------| ----------- --------------| -----------
@@ -1,16 +1,18 @@
--- ---
title: kubectl for Docker Users title: kubectl for Docker Users
content_template: templates/concept
reviewers: reviewers:
- bgrant0607 - bgrant0607
- brendandburns - brendandburns
- thockin - thockin
--- ---
You can use the Kubernetes command line tool kubectl to interact with the api. You can use kubectl if you are familiar with docker-cli. However, there are a few differences in the docker-cli commands and the kubectl commands. Each of the following section details a docker subcommand and explains the kubectl equivalent. {{% capture overview %}}
You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
{{% /capture %}}
{{< toc >}} {{% capture body %}}
## docker run
#### docker run
To run an nginx Deployment and expose the Deployment, see [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run). To run an nginx Deployment and expose the Deployment, see [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run).
@@ -57,7 +59,7 @@ To detach from the container, you can type the escape sequence Ctrl+P followed b
Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`. Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`.
To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`. To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`.
#### docker ps ## docker ps
To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get). To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get).
@@ -79,7 +81,7 @@ nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s ubuntu 0/1 Completed 0 20s
``` ```
#### docker attach ## docker attach
To attach a process that is already running in a container, see [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach). To attach a process that is already running in a container, see [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach).
@@ -107,7 +109,7 @@ $ kubectl attach -it nginx-app-5jyvm
To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.
#### docker exec ## docker exec
To execute a command in a container, see [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec). To execute a command in a container, see [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
@@ -152,7 +154,7 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/). For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
#### docker logs ## docker logs
To follow stdout/stderr of a process that is running, see [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs). To follow stdout/stderr of a process that is running, see [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs).
@@ -183,7 +185,7 @@ $ kubectl logs --previous nginx-app-zibvs
For more information, see [Logging Architecture](/docs/concepts/cluster-administration/logging/). For more information, see [Logging Architecture](/docs/concepts/cluster-administration/logging/).
#### docker stop and docker rm ## docker stop and docker rm
To stop and delete a running process, see [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete). To stop and delete a running process, see [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete).
@@ -223,11 +225,11 @@ $ kubectl get po -l run=nginx-app
**Note:** When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod. **Note:** When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
{{< /note >}} {{< /note >}}
#### docker login ## docker login
There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/docs/concepts/containers/images/#using-a-private-registry). There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/docs/concepts/containers/images/#using-a-private-registry).
#### docker version ## docker version
To get the version of client and server, see [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version). To get the version of client and server, see [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version).
@@ -255,7 +257,7 @@ Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
``` ```
#### docker info ## docker info
To get miscellaneous information about the environment and configuration, see [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info). To get miscellaneous information about the environment and configuration, see [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info).
@@ -292,3 +294,4 @@ Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/servic
Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
``` ```
{{% /capture %}}
@@ -68,7 +68,7 @@ Operation | Syntax | Description
`edit` | `kubectl edit (-f FILENAME \| TYPE NAME \| TYPE/NAME) [flags]` | Edit and update the definition of one or more resources on the server by using the default editor. `edit` | `kubectl edit (-f FILENAME \| TYPE NAME \| TYPE/NAME) [flags]` | Edit and update the definition of one or more resources on the server by using the default editor.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod, `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod,
`explain` | `kubectl explain [--include-extended-apis=true] [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc. `explain` | `kubectl explain [--include-extended-apis=true] [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
`expose` | `kubectl expose (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--port=port] [--protocol=TCP\|UDP] [--target-port=number-or-name] [--name=name] [----external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service. `expose` | `kubectl expose (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--port=port] [--protocol=TCP\|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service.
`get` | `kubectl get (-f FILENAME \| TYPE [NAME \| /NAME \| -l label]) [--watch] [--sort-by=FIELD] [[-o \| --output]=OUTPUT_FORMAT] [flags]` | List one or more resources. `get` | `kubectl get (-f FILENAME \| TYPE [NAME \| /NAME \| -l label]) [--watch] [--sort-by=FIELD] [[-o \| --output]=OUTPUT_FORMAT] [flags]` | List one or more resources.
`label` | `kubectl label (-f FILENAME \| TYPE NAME \| TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the labels of one or more resources. `label` | `kubectl label (-f FILENAME \| TYPE NAME \| TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the labels of one or more resources.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod. `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
+3
View File
@@ -84,6 +84,9 @@ yum-config-manager \
## Install docker. ## Install docker.
yum update && yum install docker-ce-18.06.1.ce yum update && yum install docker-ce-18.06.1.ce
## Create /etc/docker directory.
mkdir /etc/docker
# Setup daemon. # Setup daemon.
cat > /etc/docker/daemon.json <<EOF cat > /etc/docker/daemon.json <<EOF
{ {
@@ -70,7 +70,7 @@ For more details on the ComponentConfig have a look at [this section](#configure
Some hosts require specific kubelet configurations, due to differences in hardware, operating system, Some hosts require specific kubelet configurations, due to differences in hardware, operating system,
networking, or other host-specific parameters. The following list provides a few examples. networking, or other host-specific parameters. The following list provides a few examples.
- The path to the DNS resolution file, as specified by the `--resolve-conf` kubelet - The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
configuration flag, may differ among operating systems, or depending on whether you are using configuration flag, may differ among operating systems, or depending on whether you are using
`systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet `systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
is configured incorrectly. is configured incorrectly.
@@ -57,7 +57,7 @@ This may be caused by a number of problems. The most common are:
There are two common ways to fix the cgroup driver problem: There are two common ways to fix the cgroup driver problem:
1. Install docker again following instructions 1. Install Docker again following instructions
[here](/docs/setup/independent/install-kubeadm/#installing-docker). [here](/docs/setup/independent/install-kubeadm/#installing-docker).
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
[Configure cgroup driver used by kubelet on Master Node](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node) [Configure cgroup driver used by kubelet on Master Node](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
@@ -104,6 +104,10 @@ Right after `kubeadm init` there should not be any pods in these states.
likely that the Pod Network solution that you installed is somehow broken. You likely that the Pod Network solution that you installed is somehow broken. You
might have to grant it more RBAC privileges or use a newer version. Please file might have to grant it more RBAC privileges or use a newer version. Please file
an issue in the Pod Network providers' issue tracker and get the issue triaged there. an issue in the Pod Network providers' issue tracker and get the issue triaged there.
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.
## `coredns` (or `kube-dns`) is stuck in the `Pending` state ## `coredns` (or `kube-dns`) is stuck in the `Pending` state
+1 -1
View File
@@ -58,7 +58,7 @@ There are some important limitations of the multizone support:
* We assume that the different zones are located close to each other in the * We assume that the different zones are located close to each other in the
network, so we don't perform any zone-aware routing. In particular, traffic network, so we don't perform any zone-aware routing. In particular, traffic
that goes via services might cross zones (even if pods in some pods backing that service that goes via services might cross zones (even if some pods backing that service
exist in the same zone as the client), and this may incur additional latency and cost. exist in the same zone as the client), and this may incur additional latency and cost.
* Volume zone-affinity will only work with a `PersistentVolume`, and will not * Volume zone-affinity will only work with a `PersistentVolume`, and will not
@@ -83,7 +83,7 @@ You can add servers into your cluster by adding the cluster Profile to the serve
### Cleanup your cluster (for developers) ### Cleanup your cluster (for developers)
You can reset your cluster and wipe out all configuration and TLS certificates using the the `krib-reset-cluster` Workflow on any of the servers in the cluster. You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.
{{< caution >}} {{< caution >}}
**Caution:** When running the reset Workflow, be sure not to accidentally target your production cluster! **Caution:** When running the reset Workflow, be sure not to accidentally target your production cluster!
+1 -1
View File
@@ -32,7 +32,7 @@ a Kubernetes cluster from scratch.
## Local-machine Solutions ## Local-machine Solutions
* [Minikube](/docs/setup/minikube/) is the recommended method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account. * [Minikube](/docs/setup/minikube/) is a method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account.
* [microk8s](https://microk8s.io/) provides a single command installation of the latest Kubernetes release on a local machine for development and testing. Setup is quick, fast (~30 sec) and supports many plugins including Istio with a single command. * [microk8s](https://microk8s.io/) provides a single command installation of the latest Kubernetes release on a local machine for development and testing. Setup is quick, fast (~30 sec) and supports many plugins including Istio with a single command.
@@ -10,7 +10,6 @@ This topic discusses multiple ways to interact with clusters.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -16,7 +16,6 @@ well as any provider specific details that may be necessary.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -18,7 +18,6 @@ Dashboard also provides information on the state of Kubernetes resources in your
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -3,6 +3,7 @@ title: Extend the Kubernetes API with CustomResourceDefinitions
reviewers: reviewers:
- deads2k - deads2k
- enisoc - enisoc
- sttts
content_template: templates/task content_template: templates/task
weight: 20 weight: 20
--- ---
@@ -1,174 +0,0 @@
---
title: Migrate a ThirdPartyResource to CustomResourceDefinition
reviewers:
- enisoc
- deads2k
content_template: templates/task
weight: 50
---
{{% capture overview %}}
This page shows how to migrate data stored in a ThirdPartyResource (TPR) to a
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions) (CRD).
Kubernetes does not automatically migrate existing TPRs.
This is due to API changes introduced as part of
[graduating to beta](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/thirdpartyresources.md)
under a new name and API group.
Instead, both TPR and CRD are available and operate independently in Kubernetes 1.7.
Users must migrate each TPR one by one to preserve their data before upgrading to Kubernetes 1.8.
The simplest way to migrate is to stop all clients that use a given TPR, then delete the TPR and
start from scratch with a CRD.
This page describes an optional process that eases the transition by migrating existing TPR data for
you **on a best-effort basis**.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Make sure your Kubernetes cluster has a **master version of exactly 1.7.x** (any patch release),
as this is the only version that supports both TPR and CRD.
* If you use a TPR-based custom controller, check with the author of the controller first.
Some or all of these steps may be unnecessary if the custom controller handles the migration for
you.
* Be familiar with the concept of [custom resources](/docs/concepts/api-extension/custom-resources/),
which were known as *third-party resources* until Kubernetes 1.7.
* Be familiar with [CustomResourceDefinitions](/docs/concepts/api-extension/custom-resources/#customresourcedefinitions),
which are a simple way to implement custom resources.
* **Before performing a migration on real data, conduct a dry run by going through these steps in a test cluster.**
{{% /capture %}}
{{% capture steps %}}
## Migrate TPR data
1. **Rewrite the TPR definition**
Clients that access the REST API for your custom resource should not need any changes.
However, you will need to rewrite your TPR definition as a CRD.
Make sure you specify values for the CRD fields that match what the server used to fill in for
you with TPR.
For example, if your ThirdPartyResource looks like this:
apiVersion: extensions/v1beta1
kind: ThirdPartyResource
metadata:
name: cron-tab.stable.example.com
description: "A specification of a Pod to run on a cron style schedule"
versions:
- name: v1
A matching CustomResourceDefinition could look like this:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
scope: Namespaced
group: stable.example.com
versions:
- name: v1
served: true
storage: true
names:
kind: CronTab
plural: crontabs
singular: crontab
```
1. **Install the CustomResourceDefinition**
While the source TPR is still active, install the matching CRD with `kubectl create`.
Existing TPR data remains accessible because TPRs take precedence over CRDs when both try
to serve the same resource.
After you create the CRD, make sure the *Established* condition goes to True.
You can check it with a command like this:
```shell
kubectl get crd -o 'custom-columns=NAME:{.metadata.name},ESTABLISHED:{.status.conditions[?(@.type=="Established")].status}'
```
The output should look like this:
```console
NAME ESTABLISHED
crontabs.stable.example.com True
```
1. **Stop all clients that use the TPR**
The API server attempts to prevent TPR data for the resource from changing while it
copies objects to the CRD, but it can't guarantee consistency in all cases, such as with
[multiple masters](/docs/admin/high-availability/).
Stopping clients, such as TPR-based custom controllers, helps to avoid inconsistencies in
the copied data.
In addition, clients that watch TPR data do not receive any more events once the migration
begins.
You must restart them after the migration completes so they start watching CRD data instead.
1. **Back up TPR data**
In case the data migration fails, save a copy of existing data for the resource:
```shell
kubectl get crontabs --all-namespaces -o yaml > crontabs.yaml
```
You should also save a copy of the TPR definition if you don't have one already:
```shell
kubectl get thirdpartyresource cron-tab.stable.example.com -o yaml --export > tpr.yaml
```
1. **Delete the TPR definition**
Normally, when you delete a TPR definition, the API server tries to clean up any objects stored
in that resource.
Because a matching CRD exists, the server copies objects to the CRD instead of deleting them.
```shell
kubectl delete thirdpartyresource cron-tab.stable.example.com
```
1. **Verify the new CRD data**
It can take up to 10 seconds for the TPR controller to notice when you delete the TPR definition
and to initiate the migration. The TPR data remains accessible during this time.
Once the migration completes, the resource begins serving through the CRD.
Check that all your objects were correctly copied:
```shell
kubectl get crontabs --all-namespaces -o yaml
```
If the copy failed, you can quickly revert to the set of objects that existed just before the
migration by recreating the TPR definition:
```shell
kubectl create -f tpr.yaml
```
1. **Restart clients**
After verifying the CRD data, restart any clients you stopped before the migration, such as
custom controllers and other watchers.
These clients now access CRD data when they make requests on the same API endpoints
that the TPR previously served.
{{% /capture %}}
{{% capture whatsnext %}}
* Learn more about [custom resources](/docs/concepts/api-extension/custom-resources/).
* Learn more about [using CustomResourceDefinitions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
{{% /capture %}}
@@ -32,7 +32,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
1. List the PersistentVolumes in your cluster: 1. List the PersistentVolumes in your cluster:
```shell
kubectl get pv kubectl get pv
```
The output is similar to this: The output is similar to this:
@@ -46,13 +48,17 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
1. Choose one of your PersistentVolumes and change its reclaim policy: 1. Choose one of your PersistentVolumes and change its reclaim policy:
```shell
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
```
where `<your-pv-name>` is the name of your chosen PersistentVolume. where `<your-pv-name>` is the name of your chosen PersistentVolume.
1. Verify that your chosen PersistentVolume has the right policy: 1. Verify that your chosen PersistentVolume has the right policy:
```shell
kubectl get pv kubectl get pv
```
The output is similar to this: The output is similar to this:
@@ -15,7 +15,6 @@ running cluster.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -21,7 +21,6 @@ in the Kubernetes source directory for a canonical example.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -12,7 +12,6 @@ content_template: templates/task
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -20,7 +20,6 @@ directives.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -22,7 +22,6 @@ To dive a little deeper into implementation details, all cloud controller manage
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -18,54 +18,15 @@ vacated by the evicted critical add-on pod or the amount of resources available
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
## Rescheduler: guaranteed scheduling of critical add-ons
**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.12 in
accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**
**To avoid eviction of critical pods, you must ### Marking pod as critical
[enable priorities in scheduler](/docs/concepts/configuration/pod-priority-preemption/)
before upgrading to Kubernetes 1.10 or higher.**
Rescheduler ensures that critical pods created by DaemonSet controller are always scheduled
(assuming the cluster has enough resources to run the critical add-on pods in the absence of regular pods).
If the scheduler determines that no node has enough free resources to run the critical add-on pod
given the pods that are already running in the cluster
(indicated by critical add-on pod's pod condition PodScheduled set to false, the reason set to Unschedulable)
the rescheduler tries to free up space for the DaemonSet critical pod by evicting some pods; then the scheduler will schedule the add-on pod.
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
(see [more details](https://git.k8s.io/community/contributors/design-proposals/scheduling/taint-toleration-dedicated.md)).
Each critical add-on has to tolerate it,
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones.
## Config
Rescheduler doesn't have any user facing configuration (component config) or API.
### Marking pod as critical when using Rescheduler.
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and * Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`.
The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
A pod could also be considered critical, if its priority is greater than or equal to system-critical-priority.
### Marking pod as critical when priorites are enabled.
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).
{{% /capture %}} {{% /capture %}}
@@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -21,7 +21,7 @@ Before proceeding:
- You need to have a `kubeadm` HA cluster running version 1.11 or higher. - You need to have a `kubeadm` HA cluster running version 1.11 or higher.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md) carefully. - Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md) carefully.
- Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice. - Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm-upgrade-1-12/). - Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).
{{< note >}} {{< note >}}
**Note**: All commands on any control plane or etcd node should be **Note**: All commands on any control plane or etcd node should be
@@ -68,7 +68,7 @@ kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
The output shows that the Pod's Container has a CPU request of 500 millicpus and The output shows that the Pod's Container has a CPU request of 500 millicpus and
a CPU limit of 1 cpu. These are the default values specified by the LimitRange. a CPU limit of 1 cpu. These are the default values specified by the LimitRange.
```shel ```shell
containers: containers:
- image: nginx - image: nginx
imagePullPolicy: Always imagePullPolicy: Always
@@ -70,7 +70,7 @@ kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
The output shows that the Pod's Container has a memory request of 256 MiB and The output shows that the Pod's Container has a memory request of 256 MiB and
a memory limit of 512 MiB. These are the default values specified by the LimitRange. a memory limit of 512 MiB. These are the default values specified by the LimitRange.
```shel ```shell
containers: containers:
- image: nginx - image: nginx
imagePullPolicy: Always imagePullPolicy: Always
@@ -20,7 +20,6 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -18,7 +18,6 @@ nodes become unstable.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -23,7 +23,6 @@ on each node.
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}} {{% capture prerequisites %}}
@@ -17,7 +17,6 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -16,7 +16,6 @@ This means that the pods are visible on the API server but cannot be controlled
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -45,7 +45,7 @@ You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
kubectl --context=federation-cluster create -f mydeployment.yaml kubectl --context=federation-cluster create -f mydeployment.yaml
``` ```
The '--context=federation-cluster' flag tells kubectl to submit the The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes request to the Federation apiserver instead of sending it to a Kubernetes
cluster. cluster.
@@ -13,7 +13,6 @@ This guide explains how to use events in federation control plane to help in deb
{{% /capture %}} {{% /capture %}}
{{< toc >}}
{{% capture body %}} {{% capture body %}}
@@ -106,7 +106,7 @@ Currently the default distribution is only available on the federated HPA, but i
future, users preferences could also be specified to control and/or restrict this future, users preferences could also be specified to control and/or restrict this
distribution. distribution.
## Updating a federated ReplicaSet ## Updating a federated HPA
You can update a federated HPA as you would update a Kubernetes You can update a federated HPA as you would update a Kubernetes
HPA; however, for a federated HPA, you must send the request to HPA; however, for a federated HPA, you must send the request to
@@ -85,7 +85,7 @@ You can create a federated ingress in any of the usual ways, for example, using
kubectl --context=federation-cluster create -f myingress.yaml kubectl --context=federation-cluster create -f myingress.yaml
``` ```
For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/). For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/).
The '--context=federation-cluster' flag tells kubectl to submit the The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation API endpoint, with the appropriate request to the Federation API endpoint, with the appropriate
credentials. If you have not yet configured such a context, see the credentials. If you have not yet configured such a context, see the
[federation admin guide](/docs/admin/federation/) or one of the [federation admin guide](/docs/admin/federation/) or one of the

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