Kubernetes Prow Robot
GitHub
commit
c079d3a7cd
|
|
@ -5,6 +5,7 @@ metadata:
|
|||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ date: 2015-03-20
|
|||
slug: welcome-to-kubernetes-blog
|
||||
url: /blog/2015/03/Welcome-To-Kubernetes-Blog
|
||||
evergreen: true
|
||||
author: >
|
||||
Kit Merker (Google)
|
||||
---
|
||||
|
||||
**Author:** Kit Merker (Google)
|
||||
|
||||
Welcome to the new Kubernetes Blog. Follow this blog to learn about the Kubernetes Open Source project. We plan to post release notes, how-to articles, events, and maybe even some off topic fun here from time to time.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Kubernetes and the Mesosphere DCOS "
|
|||
date: 2015-04-22
|
||||
slug: kubernetes-and-mesosphere-dcos
|
||||
url: /blog/2015/04/Kubernetes-And-Mesosphere-Dcos
|
||||
author: >
|
||||
Craig McLuckie (Google)
|
||||
---
|
||||
|
||||
# Kubernetes and the Mesosphere DCOS
|
||||
|
|
@ -23,9 +25,5 @@ Kubernetes was designed from the start to make these capabilities available to e
|
|||
|
||||
Mesosphere, one of the earliest supporters of the Kubernetes project, has been working closely with the core Kubernetes team to create a natural experience for users looking to get the best of both worlds, adding Kubernetes to every Mesos deployment they instantiate, whether it be in the public cloud, private cloud, or in a hybrid deployment model. This is well aligned with the overall Kubernetes vision of creating ubiquitous management framework that runs anywhere a container can. It will be interesting to see how you blend together the old world and the new on a commercially supported, versatile platform.
|
||||
|
||||
Craig McLuckie
|
||||
|
||||
Product Manager, Google and Kubernetes co-founder
|
||||
|
||||
[1]: https://mesosphere.com/product/
|
||||
[2]: http://research.google.com/pubs/pub43438.html
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " AppC Support for Kubernetes through RKT "
|
|||
date: 2015-05-04
|
||||
slug: appc-support-for-kubernetes-through-rkt
|
||||
url: /blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt
|
||||
author: >
|
||||
Craig McLuckie (Google)
|
||||
---
|
||||
We very recently accepted a pull request to the Kubernetes project to add appc support for the Kubernetes community. Appc is a new open container specification that was initiated by CoreOS, and is supported through CoreOS rkt container runtime.
|
||||
|
||||
|
|
@ -21,6 +23,3 @@ Docker has done an amazing job of democratizing container technologies and makin
|
|||
|
||||
|
||||
The really nice thing is that with Kubernetes you can now pick the container runtime that works best for you based on your workloads’ needs, change runtimes without having the replace your cluster environment, or even mix together applications where different parts are running in different container runtimes in the same cluster. Additional choices can’t help but ultimately benefit the end developer.
|
||||
|
||||
-- Craig McLuckie
|
||||
Google Product Manager and Kubernetes co-founder
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Docker and Kubernetes and AppC "
|
|||
date: 2015-05-18
|
||||
slug: docker-and-kubernetes-and-appc
|
||||
url: /blog/2015/05/Docker-And-Kubernetes-And-Appc
|
||||
author: >
|
||||
Craig McLuckie (Google)
|
||||
---
|
||||
Recently we announced the intent in Kubernetes, our open source cluster manager, to support AppC and RKT, an alternative container format that has been driven by CoreOS with input from many companies (including Google). This announcement has generated a surprising amount of buzz and has been construed as a move from Google to support Appc over Docker. Many have taken it as signal that Google is moving away from supporting Docker. I would like to take a moment to clarify Google’s position in this.
|
||||
|
||||
|
|
@ -20,9 +22,3 @@ Our intent with our announcement for AppC and RKT support was to establish Kuber
|
|||
|
||||
|
||||
Stepping back a little, one must recognize that Docker has done remarkable work in democratizing container technologies and making them accessible to everyone. We believe that Docker will continue to drive great experiences for developers looking to use containers and plan to support this technology and its burgeoning community indefinitely. We, for one, are looking forward to the upcoming Dockercon where Brendan Burns (a Kubernetes co-founder) will be talking about the role of Docker in modern distributed systems design.
|
||||
|
||||
|
||||
|
||||
-- Craig McLuckie
|
||||
|
||||
Google Group Product Manager, and Kubernetes Project Co-Founder
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Kubernetes on OpenStack "
|
|||
date: 2015-05-19
|
||||
slug: kubernetes-on-openstack
|
||||
url: /blog/2015/05/Kubernetes-On-Openstack
|
||||
author: >
|
||||
Martin Buhr (independent)
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -41,6 +43,3 @@ This list will grow, and is curated [here](https://opendev.org/x/k8s-docker-suit
|
|||
|
||||
|
||||
[The Kubernetes open source project](https://github.com/GoogleCloudPlatform/kubernetes) has continued to see fantastic community adoption and increasing momentum, with over 11,000 commits and 7,648 stars on GitHub. With supporters ranging from Red Hat and Intel to CoreOS and Box.net, it has come to represent a range of customer interests ranging from enterprise IT to cutting edge startups. We encourage you to give it a try, give us your feedback, and get involved in our growing community.
|
||||
|
||||
|
||||
- Martin Buhr, Product Manager, Kubernetes Open Source Project
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@ title: Resource Usage Monitoring in Kubernetes
|
|||
date: 2015-05-12
|
||||
slug: resource-usage-monitoring-kubernetes
|
||||
url: /blog/2015/05/Resource-Usage-Monitoring-Kubernetes
|
||||
author: >
|
||||
Vishnu Kannan (Google),
|
||||
Victor Marmol (Google)
|
||||
---
|
||||
|
||||
Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes.
|
||||
|
|
@ -96,7 +99,3 @@ Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wi
|
|||
|
||||
|
||||
Now that you’ve learned a bit about Heapster, feel free to try it out on your own clusters! The [Heapster repository](https://github.com/kubernetes/heapster) is available on GitHub. It contains detailed instructions to setup Heapster and its storage backends. Heapster runs by default on most Kubernetes clusters, so you may already have it! Feedback is always welcome. Please let us know if you run into any issues via the troubleshooting channels.
|
||||
|
||||
|
||||
|
||||
_-- Vishnu Kannan and Victor Marmol, Google Software Engineers_
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " The Distributed System ToolKit: Patterns for Composite Containers "
|
|||
date: 2015-06-29
|
||||
slug: the-distributed-system-toolkit-patterns
|
||||
url: /blog/2015/06/The-Distributed-System-Toolkit-Patterns
|
||||
author: >
|
||||
Brendan Burns (Google)
|
||||
---
|
||||
Having had the privilege of presenting some ideas from Kubernetes at DockerCon 2015, I thought I would make a blog post to share some of these ideas for those of you who couldn’t be there.
|
||||
|
||||
|
|
@ -41,6 +43,4 @@ Adapter containers standardize and normalize output. Consider the task of
|
|||
|
||||
|
||||
|
||||
In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications. This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly. I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use. To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine.
|
||||
|
||||
- Brendan Burns, Software Engineer at Google
|
||||
In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications. This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly. I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use. To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " How did the Quake demo from DockerCon Work? "
|
|||
date: 2015-07-02
|
||||
slug: how-did-quake-demo-from-dockercon-work
|
||||
url: /blog/2015/07/How-Did-Quake-Demo-From-Dockercon-Work
|
||||
author: >
|
||||
Saied Kazemi (Google)
|
||||
---
|
||||
Shortly after its release in 2013, Docker became a very popular open source container management tool for Linux. Docker has a rich set of commands to control the execution of a container. Commands such as start, stop, restart, kill, pause, and unpause. However, what is still missing is the ability to Checkpoint and Restore (C/R) a container natively via Docker itself.
|
||||
|
||||
|
|
@ -189,8 +191,4 @@ If you are using a kernel older than 3.19 and your container uses AIO, you need
|
|||
|
||||
|
||||
- [torvalds: bd9b51e7](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bd9b51e7) by Al Viro
|
||||
- [torvalds: e4a0d3e72](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e4a0d3e72) by Pavel Emelyanov
|
||||
|
||||
|
||||
|
||||
- Saied Kazemi, Software Engineer at Google
|
||||
- [torvalds: e4a0d3e72](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e4a0d3e72) by Pavel Emelyanov
|
||||
|
|
@ -3,6 +3,8 @@ title: " Strong, Simple SSL for Kubernetes Services "
|
|||
date: 2015-07-14
|
||||
slug: strong-simple-ssl-for-kubernetes
|
||||
url: /blog/2015/07/Strong-Simple-Ssl-For-Kubernetes
|
||||
author: >
|
||||
Evan Brown (Google)
|
||||
---
|
||||
Hi, I’m Evan Brown [(@evandbrown](http://twitter.com/evandbrown)) and I work on the solutions architecture team for Google Cloud Platform. I recently wrote an [article](https://cloud.google.com/solutions/automated-build-images-with-jenkins-kubernetes) and [tutorial](https://github.com/GoogleCloudPlatform/kube-jenkins-imager) about using Jenkins on Kubernetes to automate the Docker and GCE image build process. Today I’m going to discuss how I used Kubernetes services and secrets to add SSL to the Jenkins web UI. After reading this, you’ll be able to add SSL termination (and HTTP-\>HTTPS redirects + basic auth) to your public HTTP Kubernetes services.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " The Growing Kubernetes Ecosystem "
|
|||
date: 2015-07-24
|
||||
slug: the-growing-kubernetes-ecosystem
|
||||
url: /blog/2015/07/The-Growing-Kubernetes-Ecosystem
|
||||
author: >
|
||||
Martin Buhr (Google)
|
||||
---
|
||||
Over the past year, we’ve seen fantastic momentum in the Kubernetes project, culminating with the release of [Kubernetes v1][4] earlier this week. We’ve also witnessed the ecosystem around Kubernetes blossom, and wanted to draw attention to some of the cooler offerings we’ve seen.
|
||||
|
||||
|
|
@ -187,7 +189,6 @@ We’ve also seen a community of services partners spring up to assist in adopti
|
|||
|
||||
|
|
||||
|
||||
\- Martin Buhr, Product Manager at Google
|
||||
|
||||
[1]: https://lh4.googleusercontent.com/2dJvY1Cl9i6SQ8apKARcisvFZPDYY5LltIsmz3W-jmon7DFE4p7cz3gsBPuz9KM_LSiuwx1xIPYr9Ygm5DTQ2f-DUyWsg7zs7YL7O3JMCHQ8Ji4B3EGpx26fbF_glQPPPp4RQTE
|
||||
[2]: http://blog.cloudbees.com/2015/07/on-demand-jenkins-slaves-with.html
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Using Kubernetes Namespaces to Manage Environments "
|
|||
date: 2015-08-28
|
||||
slug: using-kubernetes-namespaces-to-manage
|
||||
url: /blog/2015/08/Using-Kubernetes-Namespaces-To-Manage
|
||||
author: >
|
||||
Ian Lewis (Google)
|
||||
---
|
||||
##### One of the advantages that Kubernetes provides is the ability to manage various environments easier and better than traditional deployment strategies. For most nontrivial applications, you have test, staging, and production environments. You can spin up a separate cluster of resources, such as VMs, with the same configuration in staging and production, but that can be costly and managing the differences between the environments can be difficult.
|
||||
|
||||
|
|
@ -86,5 +88,3 @@ Notice that the IP addresses are different depending on which namespace is used
|
|||
While you can run staging and production environments in the same cluster and save resources and money by doing so, you will need to be careful to set up resource limits so that your staging environment doesn't starve production for CPU, memory, or disk resources. Setting resource limits properly, and testing that they are working takes a lot of time and effort so unless you can measurably save money by running production in the same cluster as staging or test, you may not really want to do that.
|
||||
|
||||
Whether or not you run staging and production in the same cluster, namespaces are a great way to partition different apps within the same cluster. Namespaces will also serve as a level where you can apply resource limits so look for more resource management features at the namespace level in the future.
|
||||
|
||||
\- Posted by Ian Lewis, Developer Advocate at Google
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Kubernetes Performance Measurements and Roadmap "
|
|||
date: 2015-09-10
|
||||
slug: kubernetes-performance-measurements-and
|
||||
url: /blog/2015/09/Kubernetes-Performance-Measurements-And
|
||||
author: >
|
||||
Wojciech Tyczynski (Google)
|
||||
---
|
||||
No matter how flexible and reliable your container orchestration system is, ultimately, you have some work to be done, and you want it completed quickly. For big problems, a common answer is to just throw more machines at the problem. After all, more compute = faster, right?
|
||||
|
||||
|
|
@ -114,7 +116,6 @@ This is by no means an exhaustive list. We will be adding new elements (or remov
|
|||
- If you have specific performance or scalability questions before then, please join our scalability special interest group on Slack: https://kubernetes.slack.com/messages/sig-scale
|
||||
- General questions? Feel free to join our Kubernetes community on Slack: https://kubernetes.slack.com/messages/kubernetes-users/
|
||||
- Submit a pull request or file an issue! You can do this in our GitHub repository. Everyone is also enthusiastically encouraged to contribute with their own experiments (and their result) or PR contributions improving Kubernetes.
|
||||
\- Wojciech Tyczynski, Google Software Engineer
|
||||
|
||||
[1]: http://kubernetes.io/images/nav_logo.svg
|
||||
[2]: http://kubernetes.io/docs/
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ title: "Some things you didn’t know about kubectl"
|
|||
date: 2015-10-28
|
||||
slug: some-things-you-didnt-know-about-kubectl_28
|
||||
url: /blog/2015/10/Some-Things-You-Didnt-Know-About-Kubectl_28
|
||||
author: >
|
||||
Brendan Burns (Google)
|
||||
---
|
||||
|
||||
**Author:** Brendan Burns (Google)
|
||||
|
||||
[kubectl](/docs/reference/kubectl/) is the command line tool for interacting with Kubernetes clusters. Many people use it every day to deploy their container workloads into production clusters. But there’s more to kubectl than just `kubectl create -f or kubectl rolling-update`. kubectl is a veritable multi-tool of container orchestration and management. Below we describe some of the features of kubectl that you may not have seen.
|
||||
|
||||
## Run interactive commands
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Creating a Raspberry Pi cluster running Kubernetes, the shopping list (
|
|||
date: 2015-11-25
|
||||
slug: creating-a-raspberry-pi-cluster-running-kubernetes-the-shopping-list-part-1
|
||||
url: /blog/2015/11/Creating-A-Raspberry-Pi-Cluster-Running-Kubernetes-The-Shopping-List-Part-1
|
||||
author: >
|
||||
Arjen Wassink (Quintor)
|
||||
---
|
||||
At Devoxx Belgium and Devoxx Morocco, Ray Tsang and I showed a Raspberry Pi cluster we built at Quintor running HypriotOS, Docker and Kubernetes. For those who did not see the talks, you can check out [an abbreviated version of the demo](https://www.youtube.com/watch?v=AAS5Mq9EktI) or the full talk by Ray on [developing and deploying Java-based microservices](https://www.youtube.com/watch?v=kT1vmK0r184) in Kubernetes. While we received many compliments on the talk, the most common question was about how to build a Pi cluster themselves! We’ll be doing just that, in two parts. This first post will cover the shopping list for the cluster, and the second will show you how to get it up and running . . .
|
||||
|
||||
|
|
@ -48,7 +50,6 @@ Building the Raspberry Pi cluster is pretty straight forward. Most of the work i
|
|||
With that, you’re all set! Next up will be running Kubernetes on the Raspberry Pi cluster. We’ll be covering this the [next post](https://kubernetes.io/blog/2015/12/creating-raspberry-pi-cluster-running), so stay tuned!
|
||||
|
||||
|
||||
Arjen Wassink, Java Architect and Team Lead, Quintor
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ date: 2015-11-09
|
|||
slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
|
||||
url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
|
||||
evergreen: true
|
||||
author: >
|
||||
David Aronchick (Google)
|
||||
---
|
||||
|
||||
**Author:** David Aronchick (Google)
|
||||
|
||||
Since the Kubernetes 1.0 release in July, we’ve seen tremendous adoption by companies building distributed systems to manage their container clusters. We’re also been humbled by the rapid growth of the community who help make Kubernetes better everyday. We have seen commercial offerings such as Tectonic by CoreOS and RedHat Atomic Host emerge to deliver deployment and support of Kubernetes. And a growing ecosystem has added Kubernetes support including tool vendors such as Sysdig and Project Calico.
|
||||
|
||||
With the help of hundreds of contributors, we’re proud to announce the availability of Kubernetes 1.1, which offers major performance upgrades, improved tooling, and new features that make applications even easier to build and deploy.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Monitoring Kubernetes with Sysdig "
|
|||
date: 2015-11-19
|
||||
slug: monitoring-kubernetes-with-sysdig
|
||||
url: /blog/2015/11/Monitoring-Kubernetes-With-Sysdig
|
||||
author: >
|
||||
Chris Crane (Sysdig)
|
||||
---
|
||||
_Today we’re sharing a guest post by Chris Crane from Sysdig about their monitoring integration into Kubernetes. _
|
||||
|
||||
|
|
@ -223,7 +225,6 @@ I’m pretty confident that what we’re delivering here represents a huge leap
|
|||
|
||||
|
||||
|
||||
Chris Crane, VP Product, Sysdig
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " One million requests per second: Dependable and dynamic distributed sys
|
|||
date: 2015-11-11
|
||||
slug: one-million-requests-per-second-dependable-and-dynamic-distributed-systems-at-scale
|
||||
url: /blog/2015/11/One-Million-Requests-Per-Second-Dependable-And-Dynamic-Distributed-Systems-At-Scale
|
||||
author: >
|
||||
Brendan Burns (Google)
|
||||
---
|
||||
|
||||
Recently, I’ve gotten in the habit of telling people that building a reliable service isn’t that hard. If you give me two Compute Engine virtual machines, a Cloud Load balancer, supervisord and nginx, I can create you a static web service that will serve a static web page, effectively forever.
|
||||
|
|
@ -30,7 +32,3 @@ I hope I’ve shown you how Kubernetes can enable developers of distributed syst
|
|||
|
||||
|
||||
"https://www.youtube.com/embed/7TOWLerX0Ps"
|
||||
|
||||
|
||||
|
||||
- Brendan Burns, Senior Staff Software Engineer, Google, Inc.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: " Creating a Raspberry Pi cluster running Kubernetes, the installation (P
|
|||
date: 2015-12-22
|
||||
slug: creating-raspberry-pi-cluster-running
|
||||
url: /blog/2015/12/Creating-Raspberry-Pi-Cluster-Running
|
||||
author: >
|
||||
Arjen Wassink (Quintor)
|
||||
---
|
||||
At Devoxx Belgium and Devoxx Morocco, [Ray Tsang](https://twitter.com/saturnism) and I ([Arjen Wassink](https://twitter.com/ArjenWassink)) showed a Raspberry Pi cluster we built at Quintor running HypriotOS, Docker and Kubernetes. While we received many compliments on the talk, the most common question was about how to build a Pi cluster themselves! We’ll be doing just that, in two parts. The [first part covered the shopping list for the cluster](https://kubernetes.io/blog/2015/11/creating-a-Raspberry-Pi-cluster-running-Kubernetes-the-shopping-list-Part-1), and this second one will show you how to get kubernetes up and running . . .
|
||||
|
||||
|
|
@ -194,6 +196,3 @@ k8s-master-127.0.0.1 3/3 Running 6 2h 127.0.0.1
|
|||
### Enjoy your Kubernetes cluster!
|
||||
|
||||
Congratulations! You now have your Kubernetes Raspberry Pi cluster running and can start playing with Kubernetes and start learning. Checkout the [Kubernetes User Guide](https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/README.md) to find out what you all can do. And don’t forget to pull some plugs occasionally like Ray and I do :-)
|
||||
|
||||
|
||||
Arjen Wassink, Java Architect and Team Lead, Quintor
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@ title: " How Weave built a multi-deployment solution for Scope using Kubernetes
|
|||
date: 2015-12-12
|
||||
slug: how-weave-built-a-multi-deployment-solution-for-scope-using-kubernetes
|
||||
url: /blog/2015/12/How-Weave-Built-A-Multi-Deployment-Solution-For-Scope-Using-Kubernetes
|
||||
author: >
|
||||
Peter Bourgon (Weaveworks)
|
||||
---
|
||||
_Today we hear from Peter Bourgon, Software Engineer at Weaveworks, a company that provides software for developers to network, monitor and control microservices-based apps in docker containers. Peter tells us what was involved in selecting and deploying Kubernetes _
|
||||
|
||||
Earlier this year at Weaveworks we launched [Weave Scope](http://weave.works/product/scope/index.html), an open source solution for visualization and monitoring of containerised apps and services. Recently we released a hosted Scope service into an [Early Access Program](http://blog.weave.works/2015/10/08/weave-the-fastest-path-to-docker-on-amazon-ec2-container-service/). Today, we want to walk you through how we initially prototyped that service, and how we ultimately chose and deployed Kubernetes as our platform.
|
||||
|
||||
|
|
@ -120,6 +121,5 @@ After a couple weeks of fighting with the machines, we were able to resolve all
|
|||
* The Kubernetes **domain language is a great match** to the problem domain.
|
||||
* We have **a lot more confidence** in operating our application (It's a lot faster, too.).
|
||||
* And we're **very happy to be part of a growing Kubernetes userbase** , contributing issues and patches as we can and benefitting from the virtuous cycle of open-source development that powers the most exciting software being written today.
|
||||
- Peter Bourgon, Software Engineer at Weaveworks
|
||||
|
||||
_Weave Scope is an open source solution for visualization and monitoring of containerised apps and services. For a hosted Scope service, request an invite to Early Access program at scope.weave.works._
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@ title: " Managing Kubernetes Pods, Services and Replication Controllers with Pup
|
|||
date: 2015-12-17
|
||||
slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
|
||||
url: /blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
|
||||
author: >
|
||||
Gareth Rushgrove (Puppet Labs)
|
||||
---
|
||||
_Today’s guest post is written by Gareth Rushgrove, Senior Software Engineer at Puppet Labs, a leader in IT automation. Gareth tells us about a new Puppet module that helps manage resources in Kubernetes. _
|
||||
|
||||
People familiar with [Puppet](https://github.com/puppetlabs/puppet) might have used it for managing files, packages and users on host computers. But Puppet is first and foremost a configuration management tool, and config management is a much broader discipline than just managing host-level resources. A good definition of configuration management is that it aims to solve four related problems: identification, control, status accounting and verification and audit. These problems exist in the operation of any complex system, and with the new [Puppet Kubernetes module](https://forge.puppetlabs.com/garethr/kubernetes) we’re starting to look at how we can solve those problems for Kubernetes.
|
||||
|
||||
|
|
@ -69,6 +70,4 @@ The advantages of using Puppet rather than just the standard YAML files and kube
|
|||
|
||||
It’s also worth noting that most large organisations will have very heterogenous environments, running a wide range of software and operating systems. Having a single toolchain that unifies those discrete systems can make adopting new technology like Kubernetes much easier.
|
||||
|
||||
It’s safe to say that Kubernetes provides an excellent set of primitives on which to build cloud-native systems. And with Puppet, you can address some of the operational and configuration management issues that come with running any complex system in production. [Let us know](mailto:gareth@puppetlabs.com) what you think if you try the module out, and what else you’d like to see supported in the future.
|
||||
|
||||
- Gareth Rushgrove, Senior Software Engineer, Puppet Labs
|
||||
It’s safe to say that Kubernetes provides an excellent set of primitives on which to build cloud-native systems. And with Puppet, you can address some of the operational and configuration management issues that come with running any complex system in production. [Let us know](mailto:gareth@puppetlabs.com) what you think if you try the module out, and what else you’d like to see supported in the future.
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ resize exceeds the maximum resources the node can ever allocate for a pod.
|
|||
|
||||
Here are a few examples where this feature may be useful:
|
||||
- Pod is running on node but with either too much or too little resources.
|
||||
- Pods are not being scheduled do to lack of sufficient CPU or memory in a
|
||||
- Pods are not being scheduled due to lack of sufficient CPU or memory in a
|
||||
cluster that is underutilized by running pods that were overprovisioned.
|
||||
- Evicting certain stateful pods that need more resources to schedule them
|
||||
on bigger nodes is an expensive or disruptive operation when other lower
|
||||
|
|
|
|||
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
title: Liveness, Readiness, and Startup Probes
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes has various types of probes:
|
||||
|
||||
- [Liveness probe](#liveness-probe)
|
||||
- [Readiness probe](#readiness-probe)
|
||||
- [Startup probe](#startup-probe)
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Liveness probe
|
||||
|
||||
Liveness probes determine when to restart a container. For example, liveness probes could catch a deadlock, when an application is running, but unable to make progress.
|
||||
|
||||
If a container fails its liveness probe repeatedly, the kubelet restarts the container.
|
||||
|
||||
Liveness probes do not wait for readiness probes to succeed. If you want to wait before
|
||||
executing a liveness probe you can either define `initialDelaySeconds`, or use a
|
||||
[startup probe](#startup-probe).
|
||||
|
||||
|
||||
## Readiness probe
|
||||
|
||||
Readiness probes determine when a container is ready to start accepting traffic. This is useful when waiting for an application to perform time-consuming initial tasks, such as establishing network connections, loading files, and warming caches.
|
||||
|
||||
If the readiness probe returns a failed state, Kubernetes removes the pod from all matching service endpoints.
|
||||
|
||||
Readiness probes runs on the container during its whole lifecycle.
|
||||
|
||||
|
||||
## Startup probe
|
||||
|
||||
A startup probe verifies whether the application within a container is started. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running.
|
||||
|
||||
If such a probe is configured, it disables liveness and readiness checks until it succeeds.
|
||||
|
||||
This type of probe is only executed at startup, unlike readiness probes, which are run periodically.
|
||||
|
||||
* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).
|
||||
|
|
@ -215,7 +215,8 @@ limits you defined.
|
|||
as restartable, Kubernetes restarts the container.
|
||||
- The memory limit for the Pod or container can also apply to pages in memory backed
|
||||
volumes, such as an `emptyDir`. The kubelet tracks `tmpfs` emptyDir volumes as container
|
||||
memory use, rather than as local ephemeral storage.
|
||||
memory use, rather than as local ephemeral storage. When using memory backed `emptyDir`,
|
||||
be sure to check the notes [below](#memory-backed-emptydir).
|
||||
|
||||
If a container exceeds its memory request and the node that it runs on becomes short of
|
||||
memory overall, it is likely that the Pod the container belongs to will be
|
||||
|
|
@ -237,6 +238,50 @@ are available in your cluster, then Pod resource usage can be retrieved either
|
|||
from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
|
||||
directly or from your monitoring tools.
|
||||
|
||||
### Considerations for memory backed `emptyDir` volumes {#memory-backed-emptydir}
|
||||
|
||||
{{< caution >}}
|
||||
If you do not specify a `sizeLimit` for an `emptyDir` volume, that volume may
|
||||
consume up to that pod's memory limit (`Pod.spec.containers[].resources.limits.memory`).
|
||||
If you do not set a memory limit, the pod has no upper bound on memory consumption,
|
||||
and can consume all available memory on the node. Kubernetes schedules pods based
|
||||
on resource requests (`Pod.spec.containers[].resources.requests`) and will not
|
||||
consider memory usage above the request when deciding if another pod can fit on
|
||||
a given node. This can result in a denial of service and cause the OS to do
|
||||
out-of-memory (OOM) handling. It is possible to create any number of `emptyDir`s
|
||||
that could potentially consume all available memory on the node, making OOM
|
||||
more likely.
|
||||
{{< /caution >}}
|
||||
|
||||
From the perspective of memory management, there are some similarities between
|
||||
when a process uses memory as a work area and when using memory-backed
|
||||
`emptyDir`. But when using memory as a volume like memory-backed `emptyDir`,
|
||||
there are additional points below that you should be careful of.
|
||||
|
||||
* Files stored on a memory-backed volume are almost entirely managed by the
|
||||
user application. Unlike when used as a work area for a process, you can not
|
||||
rely on things like language-level garbage collection.
|
||||
* The purpose of writing files to a volume is to save data or pass it between
|
||||
applications. Neither Kubernetes nor the OS may automatically delete files
|
||||
from a volume, so memory used by those files can not be reclaimed when the
|
||||
system or the pod are under memory pressure.
|
||||
* A memory-backed `emptyDir` is useful because of its performance, but memory
|
||||
is generally much smaller in size and much higher in cost than other storage
|
||||
media, such as disks or SSDs. Using large amounts of memory for `emptyDir`
|
||||
volumes may affect the normal operation of your pod or of the whole node,
|
||||
so should be used carefully.
|
||||
|
||||
If you are administering a cluster or namespace, you can also set
|
||||
[ResourceQuota](/docs/concepts/policy/resource-quotas/) that limits memory use;
|
||||
you may also want to define a [LimitRange](/docs/concepts/policy/limit-range/)
|
||||
for additional enforcement.
|
||||
If you specify a `spec.containers[].resources.limits.memory` for each Pod,
|
||||
then the muximum size of an `emptyDir` volume will be the pod's memory limit.
|
||||
|
||||
As an alternative, a cluster administrator can enforce size limits for
|
||||
`emptyDir` volumes in new Pods using a policy mechanism such as
|
||||
[ValidationAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy).
|
||||
|
||||
## Local ephemeral storage
|
||||
|
||||
<!-- feature gate LocalStorageCapacityIsolation -->
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ operator.
|
|||
{{% thirdparty-content %}}
|
||||
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
|
||||
* [Java Operator SDK](https://github.com/operator-framework/java-operator-sdk)
|
||||
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
|
||||
* [kube-rs](https://kube.rs/) (Rust)
|
||||
* [kubebuilder](https://book.kubebuilder.io/)
|
||||
|
|
|
|||
|
|
@ -632,7 +632,7 @@ The following are all the logical operators that you can use in the `operator` f
|
|||
|
||||
The following operators can only be used with `nodeAffinity`.
|
||||
|
||||
| Operator | Behaviour |
|
||||
| Operator | Behavior |
|
||||
| :------------: | :-------------: |
|
||||
| `Gt` | The field value will be parsed as an integer, and that integer is less than the integer that results from parsing the value of a label named by this selector |
|
||||
| `Lt` | The field value will be parsed as an integer, and that integer is greater than the integer that results from parsing the value of a label named by this selector |
|
||||
|
|
@ -646,7 +646,7 @@ are not available for `podAffinity`.
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
|
||||
- Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
- Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
|
||||
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
|
||||
- Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
|
||||
|
|
|
|||
|
|
@ -250,11 +250,17 @@ If that is filled up from another source (for example, log files or image
|
|||
overlays), the `emptyDir` may run out of capacity before this limit.
|
||||
|
||||
{{< note >}}
|
||||
If the `SizeMemoryBackedVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
|
||||
you can specify a size for memory backed volumes. If no size is specified, memory
|
||||
backed volumes are sized to node allocatable memory.
|
||||
You can specify a size for memory backed volumes, provided that the `SizeMemoryBackedVolumes`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is enabled in your cluster (this has been beta, and active by default, since the Kubernetes 1.22 release).
|
||||
If you don't specify a volume size, memory backed volumes are sized to node allocatable memory.
|
||||
{{< /note>}}
|
||||
|
||||
{{< caution >}}
|
||||
Please check [here](/docs/concepts/configuration/manage-resources-containers/#memory-backed-emptydir)
|
||||
for points to note in terms of resource management when using memory-backed `emptyDir`.
|
||||
{{< /caution >}}
|
||||
|
||||
#### emptyDir configuration example
|
||||
|
||||
```yaml
|
||||
|
|
@ -385,6 +391,9 @@ or as read-write, because:
|
|||
parts of the cluster.
|
||||
* Pods with identical configuration (such as created from a PodTemplate) may
|
||||
behave differently on different nodes due to different files on the nodes.
|
||||
* `hostPath` volume usage is not treated as ephemeral storage usage.
|
||||
You need to monitor the disk usage by yourself because excessive `hostPath` disk
|
||||
usage will lead to disk pressure on the node.
|
||||
{{< /warning >}}
|
||||
|
||||
Some uses for a `hostPath` are:
|
||||
|
|
|
|||
|
|
@ -680,7 +680,7 @@ The `matchPolicy` lets a webhook define how its `rules` are used to match incomi
|
|||
Allowed values are `Exact` or `Equivalent`.
|
||||
|
||||
* `Exact` means a request should be intercepted only if it exactly matches a specified rule.
|
||||
* `Equivalent` means a request should be intercepted if modifies a resource listed in `rules`,
|
||||
* `Equivalent` means a request should be intercepted if it modifies a resource listed in `rules`,
|
||||
even via another API group or version.
|
||||
|
||||
In the example given above, the webhook that only registered for `apps/v1` could use `matchPolicy`:
|
||||
|
|
|
|||
|
|
@ -155,11 +155,11 @@ the ApplySet beyond the parent object's own namespace (if any).
|
|||
The value is a comma-separated list of the names of namespaces other than the parent's namespace
|
||||
in which objects are found.
|
||||
|
||||
### applyset.kubernetes.io/contains-group-resources (alpha) {#applyset-kubernetes-io-contains-group-resources}
|
||||
### applyset.kubernetes.io/contains-group-kinds (alpha) {#applyset-kubernetes-io-contains-group-kinds}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example: `applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
Example: `applyset.kubernetes.io/contains-group-kinds: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
|
||||
Used on: Objects being used as ApplySet parents.
|
||||
|
||||
|
|
@ -176,6 +176,31 @@ or use a different optimization. However, as of Kubernetes version {{< skew curr
|
|||
it is required by kubectl. When present, the value of this annotation must be a comma separated list
|
||||
of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`.
|
||||
|
||||
### applyset.kubernetes.io/contains-group-resources (deprecated) {#applyset-kubernetes-io-contains-group-resources}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example: `applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
|
||||
Used on: Objects being used as ApplySet parents.
|
||||
|
||||
For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, ConfigMaps,
|
||||
or custom resources if the CustomResourceDefinition
|
||||
defining them has the `applyset.kubernetes.io/is-parent-type` label.
|
||||
|
||||
Part of the specification used to implement
|
||||
[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune).
|
||||
This annotation is applied to the parent object used to track an ApplySet to optimize listing of
|
||||
ApplySet member objects. It is optional in the ApplySet specification, as tools can perform discovery
|
||||
or use a different optimization. However, in Kubernetes version {{< skew currentVersion >}},
|
||||
it is required by kubectl. When present, the value of this annotation must be a comma separated list
|
||||
of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`.
|
||||
|
||||
{{< note >}}
|
||||
This annotation is currently deprecated and replaced by [`applyset.kubernetes.io/contains-group-kinds`](#applyset-kubernetes-io-contains-group-kinds),
|
||||
support for this will be removed in applyset beta or GA.
|
||||
{{< /note >}}
|
||||
|
||||
### applyset.kubernetes.io/id (alpha) {#applyset-kubernetes-io-id}
|
||||
|
||||
Type: Label
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ spec:
|
|||
Minimum storage requests are used when the underlying storage provider requires certain minimums. For example,
|
||||
AWS EBS volumes have a 1Gi minimum requirement.
|
||||
|
||||
## StorageQuota to limit PVC count and cumulative storage capacity
|
||||
## ResourceQuota to limit PVC count and cumulative storage capacity
|
||||
|
||||
Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed
|
||||
either maximum value will be rejected.
|
||||
|
|
|
|||
|
|
@ -117,10 +117,10 @@ credspec:
|
|||
DomainJoinConfig:
|
||||
DnsName: contoso.com # DNS Domain Name
|
||||
DnsTreeName: contoso.com # DNS Domain Name Root
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID of the Domain
|
||||
MachineAccountName: WebApp1 # Username of the GMSA account
|
||||
NetBiosName: CONTOSO # NETBIOS Domain Name
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID of GMSA
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID of the Domain
|
||||
```
|
||||
|
||||
The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml`
|
||||
|
|
@ -270,7 +270,7 @@ If you are having difficulties getting GMSA to work in your environment,
|
|||
there are a few troubleshooting steps you can take.
|
||||
|
||||
First, make sure the credspec has been passed to the Pod. To do this you will need
|
||||
to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
|
||||
In the example below the Pod did not get the credspec correctly:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,8 @@ weight: 140
|
|||
|
||||
This page shows how to configure liveness, readiness and startup probes for containers.
|
||||
|
||||
For more information about probes, see [Liveness, Readiness and Startup Probes](/docs/concepts/configuration/liveness-readiness-startup-probes)
|
||||
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses
|
||||
liveness probes to know when to restart a container. For example, liveness
|
||||
probes could catch a deadlock, where an application is running, but unable to
|
||||
|
|
@ -403,6 +405,7 @@ liveness and readiness checks:
|
|||
Minimum value is 1.
|
||||
* `failureThreshold`: After a probe fails `failureThreshold` times in a row, Kubernetes
|
||||
considers that the overall check has failed: the container is _not_ ready/healthy/live.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
For the case of a startup or liveness probe, if at least `failureThreshold` probes have
|
||||
failed, Kubernetes treats the container as unhealthy and triggers a restart for that
|
||||
specific container. The kubelet honors the setting of `terminationGracePeriodSeconds`
|
||||
|
|
|
|||
|
|
@ -79,9 +79,9 @@ service/php-apache created
|
|||
|
||||
## Create the HorizontalPodAutoscaler {#create-horizontal-pod-autoscaler}
|
||||
|
||||
Now that the server is running, create the autoscaler using `kubectl`. There is
|
||||
Now that the server is running, create the autoscaler using `kubectl`. The
|
||||
[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) subcommand,
|
||||
part of `kubectl`, that helps you do this.
|
||||
part of `kubectl`, helps you do this.
|
||||
|
||||
You will shortly run a command that creates a HorizontalPodAutoscaler that maintains
|
||||
between 1 and 10 replicas of the Pods controlled by the php-apache Deployment that
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
This page provides a step-by-step example of updating configuration within a Pod via a ConfigMap
|
||||
and builds upon the [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) task.
|
||||
At the end of this tutorial, you will understand how to change the configuration for a running application.
|
||||
At the end of this tutorial, you will understand how to change the configuration for a running application.
|
||||
This tutorial uses the `alpine` and `nginx` images as examples.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -27,27 +27,32 @@ documentation for your local operating system.
|
|||
|
||||
## Update configuration via a ConfigMap mounted as a Volume {#rollout-configmap-volume}
|
||||
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from [literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from
|
||||
[literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
|
||||
```shell
|
||||
kubectl create configmap sport --from-literal=sport=football
|
||||
```
|
||||
|
||||
Below is an example of a Deployment manifest with the ConfigMap `sport` mounted as a
|
||||
{{< glossary_tooltip text="volume" term_id="volume" >}} into the Pod's only container.
|
||||
{{% code_sample file="deployments/deployment-with-configmap-as-volume.yaml" %}}
|
||||
|
||||
Create the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-volume.yaml
|
||||
```
|
||||
|
||||
Check the pods for this Deployment to ensure they are ready (matching by
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}):
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=configmap-volume
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
configmap-volume-6b976dfdcf-qxvbm 1/1 Running 0 72s
|
||||
|
|
@ -55,18 +60,20 @@ configmap-volume-6b976dfdcf-skpvm 1/1 Running 0 72s
|
|||
configmap-volume-6b976dfdcf-tbc6r 1/1 Running 0 72s
|
||||
```
|
||||
|
||||
On each node where one of these Pods is running, the kubelet fetches the data for
|
||||
that ConfigMap and translates it to files in a local volume.
|
||||
The kubelet then mounts that volume into the container, as specified in the Pod template.
|
||||
The code running in that container loads the information from the file
|
||||
and uses it to print a report to stdout.
|
||||
On each node where one of these Pods is running, the kubelet fetches the data for
|
||||
that ConfigMap and translates it to files in a local volume.
|
||||
The kubelet then mounts that volume into the container, as specified in the Pod template.
|
||||
The code running in that container loads the information from the file
|
||||
and uses it to print a report to stdout.
|
||||
You can check this report by viewing the logs for one of the Pods in that Deployment:
|
||||
|
||||
```shell
|
||||
# Pick one Pod that belongs to the Deployment, and view its logs
|
||||
kubectl logs deployments/configmap-volume
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
Found 3 pods, using pod/configmap-volume-76d9c5678f-x5rgj
|
||||
Thu Jan 4 14:06:46 UTC 2024 My preferred sport is football
|
||||
|
|
@ -77,6 +84,7 @@ Thu Jan 4 14:07:26 UTC 2024 My preferred sport is football
|
|||
```
|
||||
|
||||
Edit the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl edit configmap sport
|
||||
```
|
||||
|
|
@ -102,15 +110,19 @@ metadata:
|
|||
```
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
configmap/sport edited
|
||||
```
|
||||
|
||||
Tail (follow the latest entries in) the logs of one of the pods that belongs to this Deployment:
|
||||
|
||||
```shell
|
||||
kubectl logs deployments/configmap-volume --follow
|
||||
```
|
||||
|
||||
After few seconds, you should see the log output change as follows:
|
||||
|
||||
```
|
||||
Thu Jan 4 14:11:36 UTC 2024 My preferred sport is football
|
||||
Thu Jan 4 14:11:46 UTC 2024 My preferred sport is football
|
||||
|
|
@ -119,42 +131,47 @@ Thu Jan 4 14:12:06 UTC 2024 My preferred sport is cricket
|
|||
Thu Jan 4 14:12:16 UTC 2024 My preferred sport is cricket
|
||||
```
|
||||
|
||||
When you have a ConfigMap that is mapped into a running Pod using either a
|
||||
`configMap` volume or a `projected` volume, and you update that ConfigMap,
|
||||
When you have a ConfigMap that is mapped into a running Pod using either a
|
||||
`configMap` volume or a `projected` volume, and you update that ConfigMap,
|
||||
the running Pod sees the update almost immediately.
|
||||
However, your application only sees the change if it is written to either poll for changes,
|
||||
However, your application only sees the change if it is written to either poll for changes,
|
||||
or watch for file updates.
|
||||
An application that loads its configuration once at startup will not notice a change.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
The total delay from the moment when the ConfigMap is updated to the moment when
|
||||
The total delay from the moment when the ConfigMap is updated to the moment when
|
||||
new keys are projected to the Pod can be as long as kubelet sync period.
|
||||
Also check [Mounted ConfigMaps are updated automatically](/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically).
|
||||
{{< /note >}}
|
||||
|
||||
## Update environment variables of a Pod via a ConfigMap {#rollout-configmap-env}
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from [literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from
|
||||
[literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
|
||||
```shell
|
||||
kubectl create configmap fruits --from-literal=fruits=apples
|
||||
```
|
||||
|
||||
Below is an example of a Deployment manifest with an environment variable configured via the ConfigMap `fruits`.
|
||||
|
||||
{{% code_sample file="deployments/deployment-with-configmap-as-envvar.yaml" %}}
|
||||
|
||||
Create the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-envvar.yaml
|
||||
```
|
||||
|
||||
Check the pods for this Deployment to ensure they are ready (matching by
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}):
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
configmap-env-var-59cfc64f7d-74d7z 1/1 Running 0 46s
|
||||
|
|
@ -164,11 +181,13 @@ configmap-env-var-59cfc64f7d-dpr98 1/1 Running 0 46s
|
|||
|
||||
The key-value pair in the ConfigMap is configured as an environment variable in the container of the Pod.
|
||||
Check this by viewing the logs of one Pod that belongs to the Deployment.
|
||||
|
||||
```shell
|
||||
kubectl logs deployment/configmap-env-var
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
Found 3 pods, using pod/configmap-env-var-7c994f7769-l74nq
|
||||
Thu Jan 4 16:07:06 UTC 2024 The basket is full of apples
|
||||
|
|
@ -177,6 +196,7 @@ Thu Jan 4 16:07:26 UTC 2024 The basket is full of apples
|
|||
```
|
||||
|
||||
Edit the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl edit configmap fruits
|
||||
```
|
||||
|
|
@ -185,6 +205,7 @@ In the editor that appears, change the value of key `fruits` from `apples` to `m
|
|||
The kubectl tool updates the ConfigMap accordingly (if you see an error, try again).
|
||||
|
||||
Here's an example of how that manifest could look after you edit it:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
|
|
@ -197,21 +218,23 @@ metadata:
|
|||
name: fruits
|
||||
namespace: default
|
||||
resourceVersion: "1749472"
|
||||
|
||||
```
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
configmap/fruits edited
|
||||
```
|
||||
|
||||
Tail the logs of the Deployment and observe the output for few seconds:
|
||||
|
||||
```shell
|
||||
# As the text explains, the output does NOT change
|
||||
kubectl logs deployments/configmap-env-var --follow
|
||||
```
|
||||
|
||||
Notice that the output remains **unchanged**, even though you edited the ConfigMap:
|
||||
|
||||
```
|
||||
Thu Jan 4 16:12:56 UTC 2024 The basket is full of apples
|
||||
Thu Jan 4 16:13:06 UTC 2024 The basket is full of apples
|
||||
|
|
@ -220,11 +243,16 @@ Thu Jan 4 16:13:26 UTC 2024 The basket is full of apples
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Although the value of the key inside the ConfigMap has changed, the environment variable in the Pod still shows the earlier value. This is because environment variables for a process running inside a Pod are **not** updated when the source data changes; if you wanted to force an update, you would need to have Kubernetes replace your existing Pods. The new Pods would then run with the updated information.
|
||||
Although the value of the key inside the ConfigMap has changed, the environment variable
|
||||
in the Pod still shows the earlier value. This is because environment variables for a
|
||||
process running inside a Pod are **not** updated when the source data changes; if you
|
||||
wanted to force an update, you would need to have Kubernetes replace your existing Pods.
|
||||
The new Pods would then run with the updated information.
|
||||
{{< /note >}}
|
||||
|
||||
You can trigger that replacement. Perform a rollout for the Deployment, using
|
||||
[`kubectl rollout`](/docs/reference/kubectl/generated/kubectl_rollout/):
|
||||
|
||||
```shell
|
||||
# Trigger the rollout
|
||||
kubectl rollout restart deployment configmap-env-var
|
||||
|
|
@ -234,22 +262,28 @@ kubectl rollout status deployment configmap-env-var --watch=true
|
|||
```
|
||||
|
||||
Next, check the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl get deployment configmap-env-var
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
configmap-env-var 3/3 3 3 12m
|
||||
```
|
||||
|
||||
Check the Pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var
|
||||
```
|
||||
|
||||
The rollout causes Kubernetes to make a new {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} for the Deployment; that means the existing Pods eventually terminate, and new ones are created. After few seconds, you should see an output similar to:
|
||||
The rollout causes Kubernetes to make a new {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}
|
||||
for the Deployment; that means the existing Pods eventually terminate, and new ones are created.
|
||||
After few seconds, you should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
configmap-env-var-6d94d89bf5-2ph2l 1/1 Running 0 13s
|
||||
|
|
@ -262,12 +296,14 @@ Please wait for the older Pods to fully terminate before proceeding with the nex
|
|||
{{< /note >}}
|
||||
|
||||
View the logs for a Pod in this Deployment:
|
||||
|
||||
```shell
|
||||
# Pick one Pod that belongs to the Deployment, and view its logs
|
||||
kubectl logs deployment/configmap-env-var
|
||||
```
|
||||
|
||||
You should see an output similar to the below:
|
||||
|
||||
```
|
||||
Found 3 pods, using pod/configmap-env-var-6d9ff89fb6-bzcf6
|
||||
Thu Jan 4 16:30:35 UTC 2024 The basket is full of mangoes
|
||||
|
|
@ -281,59 +317,74 @@ rollout. If Pods get created for another reason, such as scaling up the Deployme
|
|||
also use the latest configuration values; if you don't trigger a rollout, then you might find that your
|
||||
app is running with a mix of old and new environment variable values.
|
||||
|
||||
|
||||
## Update configuration via a ConfigMap in a multi-container Pod {#rollout-configmap-multiple-containers}
|
||||
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from [literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
Use the `kubectl create configmap` command to create a ConfigMap from
|
||||
[literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
|
||||
```shell
|
||||
kubectl create configmap color --from-literal=color=red
|
||||
```
|
||||
Below is an example manifest for a Deployment that manages a set of Pods, each with two containers. The two containers share an `emptyDir` volume that they use to communicate.
|
||||
The first container runs a web server (`nginx`). The mount path for the shared volume in the web server container is `/usr/share/nginx/html`. The second helper container is based on `alpine`, and for this container the `emptyDir` volume is mounted at `/pod-data`. The helper container writes a file in HTML that has its content based on a ConfigMap. The web server container serves the HTML via HTTP.
|
||||
|
||||
Below is an example manifest for a Deployment that manages a set of Pods, each with two containers.
|
||||
The two containers share an `emptyDir` volume that they use to communicate.
|
||||
The first container runs a web server (`nginx`). The mount path for the shared volume in the
|
||||
web server container is `/usr/share/nginx/html`. The second helper container is based on `alpine`,
|
||||
and for this container the `emptyDir` volume is mounted at `/pod-data`. The helper container writes
|
||||
a file in HTML that has its content based on a ConfigMap. The web server container serves the HTML via HTTP.
|
||||
|
||||
{{% code_sample file="deployments/deployment-with-configmap-two-containers.yaml" %}}
|
||||
|
||||
Create the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-two-containers.yaml
|
||||
```
|
||||
|
||||
Check the pods for this Deployment to ensure they are ready (matching by
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}):
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=configmap-two-containers
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
configmap-two-containers-565fb6d4f4-2xhxf 2/2 Running 0 20s
|
||||
configmap-two-containers-565fb6d4f4-g5v4j 2/2 Running 0 20s
|
||||
configmap-two-containers-565fb6d4f4-mzsmf 2/2 Running 0 20s
|
||||
````
|
||||
```
|
||||
|
||||
Expose the Deployment (the `kubectl` tool creates a
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} for you):
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} for you):
|
||||
|
||||
```shell
|
||||
kubectl expose deployment configmap-two-containers --name=configmap-service --port=8080 --target-port=80
|
||||
```
|
||||
|
||||
Use `kubectl` to forward the port:
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/configmap-service 8080:8080 & # this stays running in the background
|
||||
# this stays running in the background
|
||||
kubectl port-forward service/configmap-service 8080:8080 &
|
||||
```
|
||||
|
||||
Access the service.
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
Fri Jan 5 08:08:22 UTC 2024 My preferred color is red
|
||||
```
|
||||
|
||||
Edit the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl edit configmap color
|
||||
```
|
||||
|
|
@ -358,13 +409,15 @@ metadata:
|
|||
uid: 80d33e4a-cbb4-4bc9-ba8c-544c68e425d6
|
||||
```
|
||||
|
||||
Loop over the service URL for few seconds.
|
||||
Loop over the service URL for few seconds.
|
||||
|
||||
```shell
|
||||
# Cancel this when you're happy with it (Ctrl-C)
|
||||
while true; do curl --connect-timeout 7.5 http://localhost:8080; sleep 10; done
|
||||
```
|
||||
|
||||
You should see the output change as follows:
|
||||
|
||||
```
|
||||
Fri Jan 5 08:14:00 UTC 2024 My preferred color is red
|
||||
Fri Jan 5 08:14:02 UTC 2024 My preferred color is red
|
||||
|
|
@ -377,63 +430,79 @@ Fri Jan 5 08:15:00 UTC 2024 My preferred color is blue
|
|||
|
||||
## Update configuration via a ConfigMap in a Pod possessing a sidecar container {#rollout-configmap-sidecar}
|
||||
|
||||
The above scenario can be replicated by using a [Sidecar Container](/docs/concepts/workloads/pods/sidecar-containers/) as a helper container to write the HTML file.
|
||||
The above scenario can be replicated by using a [Sidecar Container](/docs/concepts/workloads/pods/sidecar-containers/)
|
||||
as a helper container to write the HTML file.
|
||||
As a Sidecar Container is conceptually an Init Container, it is guaranteed to start before the main web server container.
|
||||
This ensures that the HTML file is always available when the web server is ready to serve it.
|
||||
Please see [Enabling sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/#enabling-sidecar-containers) to utilize this feature.
|
||||
|
||||
If you are continuing from the previous scenario, you can reuse the ConfigMap named `color` for this scenario.
|
||||
If you are executing this scenario independently, use the `kubectl create configmap` command to create a ConfigMap from [literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
If you are executing this scenario independently, use the `kubectl create configmap` command to create a ConfigMap
|
||||
from [literal values](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values):
|
||||
|
||||
```shell
|
||||
kubectl create configmap color --from-literal=color=blue
|
||||
```
|
||||
|
||||
Below is an example manifest for a Deployment that manages a set of Pods, each with a main container and a sidecar container. The two containers share an `emptyDir` volume that they use to communicate.
|
||||
The main container runs a web server (NGINX). The mount path for the shared volume in the web server container is `/usr/share/nginx/html`. The second container is a Sidecar Container based on Alpine Linux which acts as a helper container. For this container the `emptyDir` volume is mounted at `/pod-data`. The Sidecar Container writes a file in HTML that has its content based on a ConfigMap. The web server container serves the HTML via HTTP.
|
||||
Below is an example manifest for a Deployment that manages a set of Pods, each with a main container and
|
||||
a sidecar container. The two containers share an `emptyDir` volume that they use to communicate.
|
||||
The main container runs a web server (NGINX). The mount path for the shared volume in the web server container
|
||||
is `/usr/share/nginx/html`. The second container is a Sidecar Container based on Alpine Linux which acts as
|
||||
a helper container. For this container the `emptyDir` volume is mounted at `/pod-data`. The Sidecar Container
|
||||
writes a file in HTML that has its content based on a ConfigMap. The web server container serves the HTML via HTTP.
|
||||
|
||||
{{% code_sample file="deployments/deployment-with-configmap-and-sidecar-container.yaml" %}}
|
||||
|
||||
Create the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-and-sidecar-container.yaml
|
||||
```
|
||||
|
||||
Check the pods for this Deployment to ensure they are ready (matching by
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}):
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=configmap-sidecar-container
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
configmap-sidecar-container-5fb59f558b-87rp7 2/2 Running 0 94s
|
||||
configmap-sidecar-container-5fb59f558b-ccs7s 2/2 Running 0 94s
|
||||
configmap-sidecar-container-5fb59f558b-wnmgk 2/2 Running 0 94s
|
||||
````
|
||||
```
|
||||
|
||||
Expose the Deployment (the `kubectl` tool creates a
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} for you):
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} for you):
|
||||
|
||||
```shell
|
||||
kubectl expose deployment configmap-sidecar-container --name=configmap-sidecar-service --port=8081 --target-port=80
|
||||
```
|
||||
|
||||
Use ```kubectl``` to forward the port:
|
||||
Use `kubectl` to forward the port:
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/configmap-sidecar-service 8081:8081 & # this stays running in the background
|
||||
# this stays running in the background
|
||||
kubectl port-forward service/configmap-sidecar-service 8081:8081 &
|
||||
```
|
||||
|
||||
Access the service.
|
||||
|
||||
```shell
|
||||
curl http://localhost:8081
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
Sat Feb 17 13:09:05 UTC 2024 My preferred color is blue
|
||||
```
|
||||
|
||||
Edit the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl edit configmap color
|
||||
```
|
||||
|
|
@ -459,12 +528,14 @@ metadata:
|
|||
```
|
||||
|
||||
Loop over the service URL for few seconds.
|
||||
|
||||
```shell
|
||||
# Cancel this when you're happy with it (Ctrl-C)
|
||||
while true; do curl --connect-timeout 7.5 http://localhost:8081; sleep 10; done
|
||||
```
|
||||
|
||||
You should see the output change as follows:
|
||||
|
||||
```
|
||||
Sat Feb 17 13:12:35 UTC 2024 My preferred color is blue
|
||||
Sat Feb 17 13:12:45 UTC 2024 My preferred color is blue
|
||||
|
|
@ -478,9 +549,11 @@ Sat Feb 17 13:13:35 UTC 2024 My preferred color is green
|
|||
## Update configuration via an immutable ConfigMap that is mounted as a volume {#rollout-configmap-immutable-volume}
|
||||
|
||||
{{< note >}}
|
||||
Immutable ConfigMaps are especially used for configuration that is constant and is **not** expected to change over time. Marking a ConfigMap as immutable allows a performance improvement where the kubelet does not watch for changes.
|
||||
Immutable ConfigMaps are especially used for configuration that is constant and is **not** expected
|
||||
to change over time. Marking a ConfigMap as immutable allows a performance improvement where the kubelet does not watch for changes.
|
||||
|
||||
If you do need to make a change, you should plan to either:
|
||||
|
||||
- change the name of the ConfigMap, and switch to running Pods that reference the new name
|
||||
- replace all the nodes in your cluster that have previously run a Pod that used the old value
|
||||
- restart the kubelet on any node where the kubelet previously loaded the old ConfigMap
|
||||
|
|
@ -490,26 +563,31 @@ An example manifest for an [Immutable ConfigMap](/docs/concepts/configuration/co
|
|||
{{% code_sample file="configmap/immutable-configmap.yaml" %}}
|
||||
|
||||
Create the Immutable ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/configmap/immutable-configmap.yaml
|
||||
```
|
||||
|
||||
Below is an example of a Deployment manifest with the Immutable ConfigMap `company-name-20150801` mounted as a
|
||||
{{< glossary_tooltip text="volume" term_id="volume" >}} into the Pod's only container.
|
||||
|
||||
{{% code_sample file="deployments/deployment-with-immutable-configmap-as-volume.yaml" %}}
|
||||
|
||||
Create the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/deployments/deployment-with-immutable-configmap-as-volume.yaml
|
||||
```
|
||||
|
||||
Check the pods for this Deployment to ensure they are ready (matching by
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}):
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
immutable-configmap-volume-78b6fbff95-5gsfh 1/1 Running 0 62s
|
||||
|
|
@ -517,13 +595,16 @@ immutable-configmap-volume-78b6fbff95-7vcj4 1/1 Running 0 62s
|
|||
immutable-configmap-volume-78b6fbff95-vdslm 1/1 Running 0 62s
|
||||
```
|
||||
|
||||
The Pod's container refers to the data defined in the ConfigMap and uses it to print a report to stdout. You can check this report by viewing the logs for one of the Pods in that Deployment:
|
||||
The Pod's container refers to the data defined in the ConfigMap and uses it to print a report to stdout.
|
||||
You can check this report by viewing the logs for one of the Pods in that Deployment:
|
||||
|
||||
```shell
|
||||
# Pick one Pod that belongs to the Deployment, and view its logs
|
||||
kubectl logs deployments/immutable-configmap-volume
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
Found 3 pods, using pod/immutable-configmap-volume-78b6fbff95-5gsfh
|
||||
Wed Mar 20 03:52:34 UTC 2024 The name of the company is ACME, Inc.
|
||||
|
|
@ -532,14 +613,15 @@ Wed Mar 20 03:52:54 UTC 2024 The name of the company is ACME, Inc.
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Once a ConfigMap is marked as immutable, it is not possible to revert this change
|
||||
Once a ConfigMap is marked as immutable, it is not possible to revert this change
|
||||
nor to mutate the contents of the data or the binaryData field.
|
||||
In order to modify the behavior of the Pods that use this configuration,
|
||||
you will create a new immutable ConfigMap and edit the Deployment
|
||||
In order to modify the behavior of the Pods that use this configuration,
|
||||
you will create a new immutable ConfigMap and edit the Deployment
|
||||
to define a slightly different pod template, referencing the new ConfigMap.
|
||||
{{< /note >}}
|
||||
|
||||
Create a new immutable ConfigMap by using the manifest shown below:
|
||||
|
||||
{{% code_sample file="configmap/new-immutable-configmap.yaml" %}}
|
||||
|
||||
```shell
|
||||
|
|
@ -547,6 +629,7 @@ kubectl apply -f https://k8s.io/examples/configmap/new-immutable-configmap.yaml
|
|||
```
|
||||
|
||||
You should see an output similar to:
|
||||
|
||||
```
|
||||
configmap/company-name-20240312 created
|
||||
```
|
||||
|
|
@ -558,15 +641,17 @@ kubectl get configmap
|
|||
```
|
||||
|
||||
You should see an output displaying both the old and new ConfigMaps:
|
||||
|
||||
```
|
||||
NAME DATA AGE
|
||||
company-name-20150801 1 22m
|
||||
company-name-20240312 1 24s
|
||||
```
|
||||
|
||||
Modify the Deployment to reference the new ConfigMap.
|
||||
Modify the Deployment to reference the new ConfigMap.
|
||||
|
||||
Edit the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl edit deployment immutable-configmap-volume
|
||||
```
|
||||
|
|
@ -580,7 +665,9 @@ volumes:
|
|||
name: company-name-20240312 # Update this field
|
||||
name: config-volume
|
||||
```
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
deployment.apps/immutable-configmap-volume edited
|
||||
```
|
||||
|
|
@ -588,6 +675,7 @@ deployment.apps/immutable-configmap-volume edited
|
|||
This will trigger a rollout. Wait for all the previous Pods to terminate and the new Pods to be in a ready state.
|
||||
|
||||
Monitor the status of the Pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume
|
||||
```
|
||||
|
|
@ -600,10 +688,10 @@ immutable-configmap-volume-5fdb88fcc8-n5jx4 1/1 Running 0 1
|
|||
immutable-configmap-volume-78b6fbff95-5gsfh 1/1 Terminating 0 32m
|
||||
immutable-configmap-volume-78b6fbff95-7vcj4 1/1 Terminating 0 32m
|
||||
immutable-configmap-volume-78b6fbff95-vdslm 1/1 Terminating 0 32m
|
||||
|
||||
```
|
||||
|
||||
You should eventually see an output similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
immutable-configmap-volume-5fdb88fcc8-29v8n 1/1 Running 0 43s
|
||||
|
|
@ -612,12 +700,14 @@ immutable-configmap-volume-5fdb88fcc8-n5jx4 1/1 Running 0 45s
|
|||
```
|
||||
|
||||
View the logs for a Pod in this Deployment:
|
||||
|
||||
```shell
|
||||
# Pick one Pod that belongs to the Deployment, and view its logs
|
||||
kubectl logs deployment/immutable-configmap-volume
|
||||
```
|
||||
|
||||
You should see an output similar to the below:
|
||||
|
||||
```
|
||||
Found 3 pods, using pod/immutable-configmap-volume-5fdb88fcc8-n5jx4
|
||||
Wed Mar 20 04:24:17 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
|
||||
|
|
@ -628,7 +718,7 @@ Wed Mar 20 04:24:37 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
|
|||
Once all the deployments have migrated to use the new immutable ConfigMap, it is advised to delete the old one.
|
||||
|
||||
```shell
|
||||
kubectl delete configmap company-name-20150801
|
||||
kubectl delete configmap company-name-20150801
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
|
@ -637,18 +727,23 @@ Changes to a ConfigMap mounted as a Volume on a Pod are available seamlessly aft
|
|||
|
||||
Changes to a ConfigMap that configures environment variables for a Pod are available after the subsequent rollout for the Pod.
|
||||
|
||||
Once a ConfigMap is marked as immutable, it is not possible to revert this change (you cannot make an immutable ConfigMap mutable), and you also cannot make any change to the contents of the `data` or the `binaryData` field. You can delete and recreate the ConfigMap, or you can make a new different ConfigMap. When you delete a ConfigMap, running containers
|
||||
and their Pods maintain a mount point to any volume that referenced that existing ConfigMap.
|
||||
|
||||
Once a ConfigMap is marked as immutable, it is not possible to revert this change
|
||||
(you cannot make an immutable ConfigMap mutable), and you also cannot make any change
|
||||
to the contents of the `data` or the `binaryData` field. You can delete and recreate
|
||||
the ConfigMap, or you can make a new different ConfigMap. When you delete a ConfigMap,
|
||||
running containers and their Pods maintain a mount point to any volume that referenced
|
||||
that existing ConfigMap.
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
Terminate the `kubectl port-forward` commands in case they are running.
|
||||
|
||||
Delete the resources created during the tutorial:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment configmap-volume configmap-env-var configmap-two-containers configmap-sidecar-container immutable-configmap-volume
|
||||
kubectl delete service configmap-service configmap-sidecar-service
|
||||
kubectl delete configmap sport fruits color company-name-20240312
|
||||
|
||||
kubectl delete configmap company-name-20150801 # In case it was not handled during the task execution
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -170,6 +170,12 @@ Kubernetes cluster. To make the `hello-node` Container accessible from outside t
|
|||
Kubernetes virtual network, you have to expose the Pod as a
|
||||
Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
|
||||
{{< warning >}}
|
||||
The agnhost container has a `/shell` endpoint, which is useful for
|
||||
debugging, but dangerous to expose to the public internet. Do not run this on an
|
||||
internet-facing cluster, or a production cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
1. Expose the Pod to the public internet using the `kubectl expose` command:
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ spec:
|
|||
labels:
|
||||
app: cassandra
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 1800
|
||||
terminationGracePeriodSeconds: 500
|
||||
containers:
|
||||
- name: cassandra
|
||||
image: gcr.io/google-samples/cassandra:v13
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ metadata:
|
|||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,218 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-1
|
||||
date: 2024-04-05T07:30:00+00:00
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
|
||||
|
||||
Ænixでは、Kubernetesに対する深い愛着があり、近いうちにすべての最新テクノロジーがKubernetesの驚くべきパターンを活用し始めることを夢見ています。
|
||||
自分だけのクラウドを構築することを考えたことはありませんか？きっと考えたことがあるでしょう。
|
||||
しかし、快適なKubernetesエコシステムを離れることなく、最新のテクノロジーとアプローチのみを使ってそれを実現することは可能でしょうか？
|
||||
Cozystackの開発における私たちの経験は、その点を深く掘り下げる必要がありました。
|
||||
自分だけのクラウドを構築することを考えたことはありませんか？
|
||||
|
||||
Kubernetesはこの目的のために設計されたものではなく、ベアメタルサーバー用にOpenStackを使用し、意図したとおりにその内部でKubernetesを実行すればよいのではないかと主張する人もいるかもしれません。
|
||||
しかし、そうすることで、単に責任があなたの手からOpenStack管理者の手に移っただけです。
|
||||
これにより、少なくとも1つの巨大で複雑なシステムがエコシステムに追加されることになります。
|
||||
|
||||
なぜ物事を複雑にするのでしょうか？
|
||||
結局のところ、Kubernetesにはテナント用のKubernetesクラスターを実行するために必要なものがすべて揃っています。
|
||||
|
||||
Kubernetesをベースにしたクラウドプラットフォームの開発における私たちの経験を共有したいと思います。
|
||||
私たち自身が使用しており、あなたの注目に値すると信じているオープンソースプロジェクトを紹介します。
|
||||
|
||||
この一連の記事では、オープンソースのテクノロジーのみを使用して、ベアメタルから管理されたKubernetesを準備する方法についての私たちの物語をお伝えします。
|
||||
データセンターの準備、仮想マシンの実行、ネットワークの分離、フォールトトレラントなストレージのセットアップといった基本的なレベルから、動的なボリュームのプロビジョニング、ロードバランサー、オートスケーリングを備えた本格的なKubernetesクラスターのプロビジョニングまでを扱います。
|
||||
|
||||
この記事から、いくつかのパートで構成されるシリーズを開始します:
|
||||
|
||||
- **パート1**: 自分のクラウドの基礎を準備する。ベアメタル上でのKubernetesの準備と運用における課題、およびインフラストラクチャをプロビジョニングするための既成のレシピ。
|
||||
- **パート2**: ネットワーク、ストレージ、仮想化。Kubernetesを仮想マシン起動のためのツールにする方法とそのために必要なもの。
|
||||
- **パート3**: Cluster APIと、ボタンを押すだけでKubernetesクラスターのプロビジョニングを開始する方法。オートスケーリング、ボリュームの動的プロビジョニング、ロードバランサーの仕組み。
|
||||
|
||||
さまざまなテクノロジーをできるだけ独立して説明しようと思いますが、同時に、私たちの経験と、なぜある解決策に至ったのかを共有します。
|
||||
|
||||
まず、Kubernetesの主な利点と、それがクラウドリソースの使用へのアプローチをどのように変えたかを理解しましょう。
|
||||
|
||||
クラウドとベアメタルでは、Kubernetesの使い方が異なることを理解することが重要です。
|
||||
|
||||
## クラウド上のKubernetes
|
||||
|
||||
クラウド上でKubernetesを運用する場合、永続ボリューム、クラウドロードバランサー、ノードのプロビジョニングプロセスを気にする必要はありません。
|
||||
これらはすべて、Kubernetesオブジェクトの形式であなたのリクエストを受け入れるクラウドプロバイダーによって処理されます。
|
||||
つまり、サーバー側は完全にあなたから隠されており、クラウドプロバイダーがどのように正確に実装しているかを知る必要はありません。
|
||||
それはあなたの責任範囲ではないからです。
|
||||
|
||||
{{< figure src="cloud.svg" alt="クラウド上のKubernetesを示す図。ロードバランシングとストレージはクラスターの外部で行われています" caption="クラウド上のKubernetesを示す図。ロードバランシングとストレージはクラスターの外部で行われています" >}}
|
||||
|
||||
Kubernetesは、どこでも同じように機能する便利な抽象化を提供しているため、あらゆるクラウドのKubernetes上にアプリケーションをデプロイできます。
|
||||
|
||||
クラウドでは、Kubernetesコントロールプレーン、仮想マシン、永続ボリューム、ロードバランサーなど、いくつかの個別のエンティティを持つことが非常に一般的です。
|
||||
これらのエンティティを使用することで、高度に動的な環境を作成できます。
|
||||
|
||||
Kubernetesのおかげで、仮想マシンは今やクラウドリソースを利用するための単なるユーティリティエンティティとしてのみ見られるようになりました。
|
||||
もはや仮想マシンの中にデータを保存することはありません。
|
||||
仮想マシンをすべて削除して、アプリケーションを壊すことなく再作成できます。
|
||||
Kubernetesコントロールプレーンは、クラスター内で何が実行されるべきかについての情報を保持し続けます。
|
||||
ロードバランサーは、新しいノードにトラフィックを送信するためにエンドポイントを変更するだけで、ワークロードにトラフィックを送信し続けます。
|
||||
そして、データはクラウドが提供する外部の永続ボリュームに安全に保存されます。
|
||||
|
||||
このアプローチは、クラウドでKubernetesを使用する際の基本です。
|
||||
その理由はかなり明白です。
|
||||
システムが単純であるほど安定性が高くなり、このシンプルさのためにクラウドでKubernetesを選択するのです。
|
||||
|
||||
## ベアメタル上のKubernetes
|
||||
|
||||
クラウドでKubernetesを使用することは本当に簡単で便利ですが、ベアメタルへのインストールについては同じことが言えません。
|
||||
ベアメタルの世界では、Kubernetesは逆に非常に複雑になります。
|
||||
まず、ネットワーク全体、バックエンドストレージ、クラウドバランサーなどは、通常、クラスターの外部ではなく内部で実行されるためです。
|
||||
その結果、このようなシステムは更新と保守がはるかに難しくなります。
|
||||
|
||||
{{< figure src="baremetal.svg" alt="ベアメタル上のKubernetesを示す図。ロードバランシングとストレージはクラスターの内部で行われています" caption="ベアメタル上のKubernetesを示す図。ロードバランシングとストレージはクラスターの内部で行われています" >}}
|
||||
|
||||
ご自身で判断してみてください。
|
||||
クラウドでは、通常、ノードを更新するために仮想マシンを削除する(または`kubectl delete node`を使用する)だけで、イミュータブルなイメージに基づいて新しいノードを作成することをノード管理ツールに任せることができます。
|
||||
新しいノードはクラスターに参加し、Kubernetesの世界で非常にシンプルでよく使われるパターンに従って、ノードとして「そのまま動作」します。
|
||||
多くのクラスターでは、安価なスポットインスタンスを利用できるため、数分ごとに新しい仮想マシンをオーダーしています。
|
||||
しかし、物理サーバーを使用している場合は、簡単に削除して再作成することはできません。
|
||||
まず、物理サーバーはクラスターサービスを実行していたり、データを保存していたりすることが多いため、その更新プロセスははるかに複雑になるからです。
|
||||
|
||||
この問題を解決するアプローチはさまざまです。
|
||||
kubeadm、kubespray、k3sが行うようなインプレースアップデートから、Cluster APIとMetal3を通じた物理ノードのプロビジョニングの完全な自動化まで幅広くあります。
|
||||
|
||||
私は、Talos Linuxが提供するハイブリッドアプローチが気に入っています。
|
||||
このアプローチでは、システム全体が単一の設定ファイルで記述されます。
|
||||
このファイルのほとんどのパラメーターは、Kubernetesコントロールプレーンコンポーネントのバージョンを含め、ノードを再起動または再作成することなく適用できます。
|
||||
それでも、Kubernetesの宣言的な性質を最大限に保持しています。
|
||||
このアプローチは、ベアメタルノードを更新する際のクラスターサービスへの不要な影響を最小限に抑えます。
|
||||
ほとんどの場合、マイナーアップデートの際に仮想マシンを移行したり、クラスターファイルシステムを再構築したりする必要はありません。
|
||||
|
||||
## 将来のクラウドの基盤を準備する
|
||||
|
||||
さて、自分だけのクラウドを構築することに決めたとしましょう。
|
||||
まずは基盤となるレイヤーが必要です。
|
||||
サーバーにKubernetesをインストールする方法だけでなく、それをどのように更新し、維持していくかについても考える必要があります。
|
||||
カーネルの更新、必要なモジュールのインストール、パッケージやセキュリティパッチなどについても考えなければならないことを考慮してください。
|
||||
クラウド上の既製のKubernetesを使用する際に気にする必要のないことをはるかに多く考えなければなりません。
|
||||
|
||||
もちろん、UbuntuやDebianのような標準的なディストリビューションを使用できますし、Flatcar Container Linux、Fedora Core、Talos Linuxのような特殊なディストリビューションを検討することもできます。
|
||||
それぞれに長所と短所があります。
|
||||
|
||||
私たちのことですか？
|
||||
Ænixでは、ZFS、DRBD、OpenvSwitchなどのかなり特殊なカーネルモジュールを使用しているので、必要なモジュールをすべて事前に含んだシステムイメージを形成する方法を選びました。
|
||||
この場合、Talos Linuxが私たちにとって最も便利であることがわかりました。
|
||||
たとえば、次のような設定で、必要なカーネルモジュールをすべて含むシステムイメージを構築するのに十分です:
|
||||
|
||||
```yaml
|
||||
arch: amd64
|
||||
platform: metal
|
||||
secureboot: false
|
||||
version: v1.6.4
|
||||
input:
|
||||
kernel:
|
||||
path: /usr/install/amd64/vmlinuz
|
||||
initramfs:
|
||||
path: /usr/install/amd64/initramfs.xz
|
||||
baseInstaller:
|
||||
imageRef: ghcr.io/siderolabs/installer:v1.6.4
|
||||
systemExtensions:
|
||||
- imageRef: ghcr.io/siderolabs/amd-ucode:20240115
|
||||
- imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115
|
||||
- imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115
|
||||
- imageRef: ghcr.io/siderolabs/i915-ucode:20240115
|
||||
- imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115
|
||||
- imageRef: ghcr.io/siderolabs/intel-ucode:20231114
|
||||
- imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115
|
||||
- imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4
|
||||
- imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4
|
||||
output:
|
||||
kind: installer
|
||||
outFormat: raw
|
||||
```
|
||||
|
||||
`docker`コマンドラインツールを使用して、OSイメージをビルドします:
|
||||
|
||||
```
|
||||
cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" -
|
||||
```
|
||||
|
||||
その結果、必要なものがすべて含まれたDockerコンテナイメージが得られます。
|
||||
このイメージを使用して、サーバーにTalos Linuxをインストールできます。
|
||||
同じことができます。このイメージには、必要なすべてのファームウェアとカーネルモジュールが含まれます。
|
||||
|
||||
しかし、新しく形成されたイメージをノードにどのように配信するかという問題が発生します。
|
||||
|
||||
しばらくの間、PXEブートのアイデアについて考えていました。
|
||||
たとえば、2年前に[記事](/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/)を書いた**Kubefarm**プロジェクトは、完全にこのアプローチを使用して構築されました。
|
||||
しかし残念ながら、他のクラスターを保持する最初の親クラスターをデプロイするのに役立つわけではありません。
|
||||
そこで今回、PXEアプローチを使用して同じことを行うのに役立つソリューションを用意しました。
|
||||
|
||||
基本的に必要なのは、コンテナ内で一時的な**DHCP**と**PXE**サーバーを[実行する](https://cozystack.io/docs/get-started/)ことだけです。
|
||||
そうすれば、ノードはあなたのイメージから起動し、Debianベースの簡単なスクリプトを使用して、ノードのブートストラップに役立てることができます。
|
||||
|
||||
[](https://asciinema.org/a/627123)
|
||||
|
||||
`talos-bootstrap`スクリプトの[ソースコード](https://github.com/aenix-io/talos-bootstrap/)はGitHubで入手できます。
|
||||
|
||||
このスクリプトを使用すると、ベアメタル上に5分でKubernetesをデプロイし、それにアクセスするためのkubeconfigを取得できます。
|
||||
しかし、まだ多くの未解決の問題が残っています。
|
||||
|
||||
## システムコンポーネントの配信
|
||||
|
||||
この段階では、さまざまなワークロードを実行できるKubernetesクラスターがすでに手に入っています。
|
||||
しかし、まだ完全に機能しているわけではありません。
|
||||
つまり、ネットワークとストレージを設定する必要があるだけでなく、仮想マシンを実行するためのKubeVirtや、監視スタックやその他のシステム全体のコンポーネントなど、必要なクラスター拡張機能をインストールする必要があります。
|
||||
|
||||
従来、これは**Helmチャート**をクラスターにインストールすることで解決されています。
|
||||
ローカルで`helm install`コマンドを実行することで実現できますが、アップデートを追跡したい場合や、複数のクラスターを持っていてそれらを均一に保ちたい場合、このアプローチは不便になります。
|
||||
実際には、これを宣言的に行う方法はたくさんあります。
|
||||
これを解決するには、最高のGitOpsプラクティスを使用することをお勧めします。
|
||||
つまり、ArgoCDやFluxCDのようなツールを指します。
|
||||
|
||||
ArgoCDはグラフィカルインターフェースと中央コントロールプレーンを備えているため開発目的には便利ですが、一方でFluxCDはKubernetesディストリビューションの作成により適しています。
|
||||
FluxCDを使用すると、どのチャートをどのパラメーターで起動すべきかを指定し、依存関係を記述できます。
|
||||
そうすれば、FluxCDがすべてを処理してくれます。
|
||||
|
||||
新しく作成したクラスターにFluxCDを1回インストールし、適切に設定することをお勧めします。
|
||||
これにより、FluxCDは必要不可欠なコンポーネントをすべて自動的にデプロイできるようになり、クラスターを目的の状態にアップグレードできます。
|
||||
たとえば、私たちのプラットフォームをインストールすると、システムコンポーネントとともに次の事前設定されたHelmチャートが表示されます:
|
||||
|
||||
```
|
||||
NAMESPACE NAME AGE READY STATUS
|
||||
cozy-cert-manager cert-manager 4m1s True Release reconciliation succeeded
|
||||
cozy-cert-manager cert-manager-issuers 4m1s True Release reconciliation succeeded
|
||||
cozy-cilium cilium 4m1s True Release reconciliation succeeded
|
||||
cozy-cluster-api capi-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-cluster-api capi-providers 4m1s True Release reconciliation succeeded
|
||||
cozy-dashboard dashboard 4m1s True Release reconciliation succeeded
|
||||
cozy-fluxcd cozy-fluxcd 4m1s True Release reconciliation succeeded
|
||||
cozy-grafana-operator grafana-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-kamaji kamaji 4m1s True Release reconciliation succeeded
|
||||
cozy-kubeovn kubeovn 4m1s True Release reconciliation succeeded
|
||||
cozy-kubevirt-cdi kubevirt-cdi 4m1s True Release reconciliation succeeded
|
||||
cozy-kubevirt-cdi kubevirt-cdi-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-kubevirt kubevirt 4m1s True Release reconciliation succeeded
|
||||
cozy-kubevirt kubevirt-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-linstor linstor 4m1s True Release reconciliation succeeded
|
||||
cozy-linstor piraeus-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-mariadb-operator mariadb-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-metallb metallb 4m1s True Release reconciliation succeeded
|
||||
cozy-monitoring monitoring 4m1s True Release reconciliation succeeded
|
||||
cozy-postgres-operator postgres-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-rabbitmq-operator rabbitmq-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-redis-operator redis-operator 4m1s True Release reconciliation succeeded
|
||||
cozy-telepresence telepresence 4m1s True Release reconciliation succeeded
|
||||
cozy-victoria-metrics-operator victoria-metrics-operator 4m1s True Release reconciliation succeeded
|
||||
```
|
||||
|
||||
## まとめ
|
||||
|
||||
結果として、誰にでも提供できる高い再現性を持つ環境を実現でき、意図したとおりに動作することがわかります。
|
||||
これは、実際に[Cozystack](https://github.com/aenix-io/cozystack)プロジェクトが行っていることであり、あなた自身が無料で試すことができます。
|
||||
|
||||
次の記事では、[仮想マシンを実行するためのKubernetesの準備方法](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-2/)と[ボタンをクリックするだけでKubernetesクラスターを実行する方法](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-3/)について説明します。
|
||||
ご期待ください。きっと面白いはずです！
|
||||
|
|
@ -0,0 +1,196 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート2)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-2
|
||||
date: 2024-04-05T07:35:00+00:00
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) ([IDC Frontier Inc.](https://www.idcf.jp/)), [Daiki Hayakawa(bells17)](https://github.com/bells17) ([3-shake Inc.](https://3-shake.com/en/)), [atoato88](https://github.com/atoato88) ([NEC Corporation](https://jpn.nec.com/index.html)), [Kaito Ii](https://github.com/kaitoii11) ([Hewlett Packard Enterprise](https://www.hpe.com/jp/ja/home.html))
|
||||
|
||||
Kubernetesエコシステムだけを使って自分だけのクラウドを構築する方法について、一連の記事を続けています。
|
||||
[前回の記事](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/)では、Talos LinuxとFlux CDをベースにした基本的なKubernetes ディストリビューションの準備方法を説明しました。
|
||||
この記事では、Kubernetesにおけるさまざまな仮想化テクノロジーをいくつか紹介し、主にストレージとネットワークを中心に、Kubernetes内で仮想マシンを実行するために必要な環境を整えます。
|
||||
|
||||
KubeVirt、LINSTOR、Kube-OVNなどのテクノロジーについて取り上げる予定です。
|
||||
|
||||
しかし最初に、仮想マシンが必要な理由と、クラウドの構築にDockerコンテナを使用するだけでは不十分である理由を説明しましょう。
|
||||
その理由は、コンテナが十分なレベルの分離を提供していないことにあります。
|
||||
状況は年々改善されていますが、コンテナのサンドボックスから脱出してシステムの特権を昇格させる脆弱性が見つかることがよくあります。
|
||||
|
||||
一方、Kubernetesはもともとマルチテナントシステムとして設計されていなかったため、基本的な使用パターンでは、独立したプロジェクトや開発チームごとに別々のKubernetesクラスターを作成することが一般的です。
|
||||
|
||||
仮想マシンは、クラウド環境でテナント同士を分離するための主要な手段です。
|
||||
仮想マシン内では、ユーザーは管理者権限でコードやプログラムを実行できますが、これは他のテナントや環境自体に影響を与えません。
|
||||
つまり、仮想マシンは[ハードマルチテナンシー分離](/docs/concepts/security/multi-tenancy/#isolation)を実現し、テナント間で信頼関係がない環境でも安全に実行できます。
|
||||
|
||||
## Kubernetes における仮想化テクノロジー
|
||||
|
||||
Kubernetesの世界に仮想化をもたらすテクノロジーはいくつかありますが、[KubeVirt](https://kubevirt.io/)と[Kata Containers](https://katacontainers.io/)が最も一般的です。
|
||||
ただし、これらの動作方式は異なることを理解しておく必要があります。
|
||||
|
||||
**Kata Containers**は、CRI(Container Runtime Interface)を実装しており、標準のコンテナを仮想マシン内で実行することで、追加の分離レベルを提供します。
|
||||
ただし、これらは同一のKubernetesクラスター内で動作します。
|
||||
|
||||
{{< figure src="kata-containers.svg" caption="コンテナを仮想マシン内で実行することにより、Kata Containersがコンテナの分離を確保する方法を示す図" alt="コンテナを仮想マシン内で実行することにより、Kata Containersがコンテナの分離を確保する方法を示す図" >}}
|
||||
|
||||
KubeVirtは、Kubernetes APIを使用して従来の仮想マシンを実行できます。
|
||||
KubeVirtの仮想マシンは、コンテナ内の通常のLinuxプロセスとして実行されます。
|
||||
つまり、KubeVirtでは、コンテナが仮想マシン(QEMU)プロセスを実行するためのサンドボックスとして使用されます。
|
||||
これは、以下の図で、KubeVirtにおける仮想マシンのライブマイグレーションの実装方法を見ると明らかです。
|
||||
マイグレーションが必要な場合、仮想マシンはあるコンテナから別のコンテナに移動します。
|
||||
|
||||
{{< figure src="kubevirt-migration.svg" caption="KubeVirtにおいて、仮想マシンがあるコンテナから別のコンテナへライブマイグレーションする様子を示す図" alt="KubeVirtにおいて、仮想マシンがあるコンテナから別のコンテナへライブマイグレーションする様子を示す図" >}}
|
||||
|
||||
[Cloud-Hypervisor](https://github.com/cloud-hypervisor/cloud-hypervisor)を使用した軽量な仮想化を実装し、初期からCluster APIを使用した仮想Kubernetesクラスターの実行に重点を置いている代替プロジェクト[Virtink](https://github.com/smartxworks/virtink)もあります。
|
||||
|
||||
私たちの目標を考慮して、この分野で最も一般的なプロジェクトであるKubeVirtを使用することに決めました。
|
||||
さらに、私たちはKubeVirtに関する豊富な専門知識を持ち、すでに多くの貢献をしています。
|
||||
|
||||
KubeVirtは[インストールが簡単](https://kubevirt.io/user-guide/operations/installation/)で、[containerDisk](https://kubevirt.io/user-guide/virtual_machines/disks_and_volumes/#containerdisk)機能を使用してすぐに仮想マシンを実行できます。
|
||||
この機能により、VMイメージをコンテナイメージレジストリから直接OCIイメージとして保存および配布できます。
|
||||
containerDiskを使用した仮想マシンは、Kubernetesワーカーノードやその他の状態の永続化を必要としない仮想マシンの作成に適しています。
|
||||
|
||||
永続データを管理するために、KubeVirtは別のツールであるContainerized Data Importer(CDI)を提供しています。
|
||||
CDIを使用すると、PVCのクローンを作成し、ベースイメージからデータを取り込むことができます。
|
||||
CDIは、仮想マシンの永続ボリュームを自動的にプロビジョニングする場合や、テナントKubernetesクラスターからの永続ボリューム要求を処理するために使用されるKubeVirt CSIドライバーにも必要となります。
|
||||
|
||||
しかし最初に、これらのデータをどこにどのように保存するかを決める必要があります。
|
||||
|
||||
## Kubernetes上の仮想マシン用ストレージ
|
||||
|
||||
CSI(Container Storage Interface)の導入により、Kubernetesと統合できる幅広いテクノロジーが利用可能になりました。
|
||||
実際、KubeVirtはCSIインターフェースを完全に活用しており、仮想化のためのストレージの選択肢はKubernetes自体のストレージの選択肢と密接に連携しています。
|
||||
しかし、考慮すべき細かな差異があります。
|
||||
通常、標準のファイルシステムを使用するコンテナとは異なり、仮想マシンにはブロックデバイスの方が効率的です。
|
||||
|
||||
KubernetesのCSIインターフェースでは、ファイルシステムとブロックデバイスの両方のタイプのボリュームを要求できますが、使用しているストレージバックエンドがこれをサポートしていることを確認することが重要です。
|
||||
|
||||
仮想マシンにブロックデバイスを使用すると、ファイルシステムなどの追加の抽象化レイヤーが不要になるため、パフォーマンスが向上し、ほとんどの場合で _ReadWriteMany_ モードの使用が可能になります。
|
||||
このモードでは、複数のノードから同時にボリュームにアクセスできるため、KubeVirtにおける仮想マシンのライブマイグレーションを有効にするための重要な機能です。
|
||||
|
||||
ストレージシステムは、外部または内部(ハイパーコンバージドインフラストラクチャの場合)にすることができます。
|
||||
多くの場合、外部ストレージを使用するとデータが計算ノードから分離して保存されるため、システム全体の安定性が向上します。
|
||||
|
||||
{{< figure src="storage-external.svg" caption="計算ノードと通信する外部データストレージを示す図" alt="計算ノードと通信する外部データストレージを示す図" >}}
|
||||
|
||||
外部ストレージソリューションは、エンタープライズシステムでよく使用されています。
|
||||
このようなストレージは、多くの場合運用を担当する外部ベンダーによって提供されるためです。
|
||||
Kubernetesとの統合には、クラスターにインストールされる小さなコンポーネントであるCSIドライバーのみが関与します。
|
||||
このドライバーは、このストレージにボリュームをプロビジョニングし、Kubernetesによって実行されるPodにそれらをアタッチする役割を担います。
|
||||
ただし、このようなストレージソリューションは、純粋にオープンソースのテクノロジーを使用して実装することもできます。
|
||||
人気のあるソリューションの1つは、[democratic-csi](https://github.com/democratic-csi/democratic-csi)ドライバーを使用した[TrueNAS](https://www.truenas.com/)です。
|
||||
|
||||
{{< figure src="storage-local.svg" caption="コンピュートノード上で実行されるローカルデータストレージを示す図" alt="コンピュートノード上で実行されるローカルデータストレージを示す図" >}}
|
||||
|
||||
一方、ハイパーコンバージドシステムは、多くの場合、ローカルストレージ(レプリケーションが不要な場合)と、[Rook/Ceph](https://rook.io/)、[OpenEBS](https://openebs.io/)、[Longhorn](https://longhorn.io/)、[LINSTOR](https://linbit.com/linstor/)などのソフトウェアデファインドストレージを使用して実装されます。
|
||||
これらは、多くの場合、Kubernetesに直接インストールされます。
|
||||
|
||||
{{< figure src="storage-clustered.svg" caption="コンピュートノード上で実行されるクラスター化データストレージを示す図" alt="コンピュートノード上で実行されるクラスター化データストレージを示す図" >}}
|
||||
|
||||
ハイパーコンバージドシステムには利点があります。
|
||||
たとえば、データの局所性です。
|
||||
データがローカルに保存されている場合、そのデータへのアクセスは高速になります。
|
||||
しかし、このようなシステムは通常、管理と保守がより難しいという欠点があります。
|
||||
|
||||
Ænixでは、追加の外部ストレージを購入してセットアップする必要なく使用でき、速度とリソースの利用の点で最適な、すぐに使える解決策を提供したいと考えていました。
|
||||
LINSTORがその解決策となりました。
|
||||
バックエンドとして業界で人気のある実績あるテクノロジーであるLVMやZFSを使用していることで、データが安全に保存されていることに自信が持てます。
|
||||
DRDBベースのレプリケーションは信じられないほど高速で、少ない計算リソースしか消費しません。
|
||||
|
||||
Kubernetes上でLINSTORをインストールするには、PiraeusプロジェクトがKubeVirtで使用できる既製のブロックストレージをすでに提供しています。
|
||||
|
||||
{{< note >}}
|
||||
[前回の記事](/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/)で説明したように、Talos Linuxを使用している場合は、必要なカーネルモジュールを事前に有効にし、[手順](https://github.com/piraeusdatastore/piraeus-operator/blob/v2/docs/how-to/talos.md)に従ってPiraeusを設定する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
## Kubernetes上の仮想マシン用ネットワーク
|
||||
|
||||
Kubernetesのネットワークアーキテクチャは同じようなインターフェースであるCNIを持っているにもかかわらず、実際にはより複雑で、通常、互いに直接接続されていない多くの独立したコンポーネントで構成されています。
|
||||
実際、Kubernetesのネットワークは以下に説明する4つのレイヤーに分割できます。
|
||||
|
||||
### ノードネットワーク (データセンターネットワーク)
|
||||
|
||||
ノードが相互に接続されるネットワークです。
|
||||
このネットワークは通常、Kubernetesによって管理されませんが、これがないと何も機能しないため、重要なネットワークです。
|
||||
実際には、ベアメタルインフラストラクチャには通常、複数のこのようなネットワークがあります。
|
||||
例えば、ノード間通信用の1つ、ストレージレプリケーション用の2つ目、外部アクセス用の3つ目などです。
|
||||
|
||||
{{< figure src="net-nodes.svg" caption="Kubernetesのネットワーク構成におけるノードネットワーク(データセンターネットワーク)の役割を示す図" alt="Kubernetesのネットワーク構成におけるノードネットワーク(データセンターネットワーク)の役割を示す図" >}}
|
||||
|
||||
ノード間の物理ネットワークの相互作用の設定は、ほとんどの状況でKubernetesが既存のネットワークインフラストラクチャを利用するため、この記事の範囲を超えています。
|
||||
|
||||
### Podネットワーク
|
||||
|
||||
これは、CNIプラグインによって提供されるネットワークです。
|
||||
CNIプラグインの役割は、クラスター内のすべてのコンテナとノード間の透過的な接続を確保することです。
|
||||
ほとんどのCNIプラグインは、各ノードで使用するためにIPアドレスの個別のブロックが割り当てられるフラットネットワークを実装しています。
|
||||
|
||||
{{< figure src="net-pods.svg" caption="Kubernetesのネットワーク構成におけるPodネットワーク(CNIプラグイン)の役割を示す図" alt="Kubernetesのネットワーク構成におけるPodネットワーク(CNIプラグイン)の役割を示す図" >}}
|
||||
|
||||
実際には、クラスターには[Multus](https://github.com/k8snetworkplumbingwg/multus-cni)によって管理される複数のCNIプラグインを持つことができます。
|
||||
このアプローチは、[Rancher](https://www.rancher.com/)や[OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift/virtualization)などのKubeVirtベースの仮想化ソリューションでよく使用されます。
|
||||
プライマリCNIプラグインはKubernetesサービスとの統合に使用され、追加のCNIプラグインはプライベートネットワーク(VPC)の実装やデータセンターの物理ネットワークとの統合に使用されます。
|
||||
|
||||
[デフォルトのCNIプラグイン](https://github.com/containernetworking/plugins/tree/main/plugins)は、ブリッジまたは物理インターフェースの接続に使用できます。
|
||||
さらに、パフォーマンスを向上させるために設計された[macvtap-cni](https://github.com/kubevirt/macvtap-cni)などの専用プラグインもあります。
|
||||
|
||||
Kubernetes内で仮想マシンを実行する際に注意すべきもう1つの側面は、特にMultusによって提供されるセカンダリインターフェースに対するIPAM(IPアドレス管理)の必要性です。
|
||||
これは通常、インフラストラクチャ内で動作するDHCPサーバーによって管理されます。
|
||||
さらに、仮想マシンのMACアドレスの割り当ては、[Kubemacpool](https://github.com/k8snetworkplumbingwg/kubemacpool)によって管理できます。
|
||||
|
||||
私たちのプラットフォームでは、別の方法を選択し、[Kube-OVN](https://www.kube-ovn.io/)に完全に頼ることにしました。
|
||||
このCNIプラグインは、もともとOpenStack用に開発されたOVN(Open Virtual Network)をベースにしています。
|
||||
Kube-OVNはKubernetes内の仮想マシン用の完全なネットワークソリューションを提供します。
|
||||
IPとMACアドレスを管理するためのカスタムリソースを備え、ノード間でIPアドレスを保持したままライブマイグレーションをサポートし、テナント間の物理ネットワーク分離用のVPCの作成を可能にします。
|
||||
|
||||
Kube-OVNでは、名前空間全体に個別のサブネットを割り当てたり、Multusを使用して追加のネットワークインターフェースとして接続したりできます。
|
||||
|
||||
### サービスネットワーク
|
||||
|
||||
CNIプラグインに加えて、Kubernetesにはサービスネットワークもあります。これは主にサービスディスカバリーに必要です。
|
||||
従来の仮想マシンとは異なり、KubernetesはもともとランダムなアドレスでPodを実行するように設計されています。
|
||||
そして、サービスネットワークは、トラフィックを常に正しいPodに誘導する便利な抽象化(安定したIPアドレスとDNS名)を提供します。
|
||||
仮想マシンのIPは通常静的であるにもかかわらず、このアプローチはクラウド内の仮想マシンでも一般的に使用されています。
|
||||
|
||||
{{< figure src="net-services.svg" caption="Kubernetesのネットワーク構成におけるサービスネットワーク(サービスネットワークプラグイン)の役割を示す図" alt="Kubernetesのネットワーク構成におけるサービスネットワーク(サービスネットワークプラグイン)の役割を示す図" >}}
|
||||
|
||||
Kubernetesでのサービスネットワークの実装は、サービスネットワークプラグインによって処理されます。
|
||||
標準の実装は**kube-proxy**と呼ばれ、ほとんどのクラスターで使用されています。
|
||||
しかし最近では、この機能はCNIプラグインの一部として提供されることがあります。
|
||||
最も先進的な実装は、[Cilium](https://cilium.io/)プロジェクトによって提供されており、kube-proxyの代替モードで実行できます。
|
||||
|
||||
CiliumはeBPFテクノロジーに基づいており、Linuxネットワークスタックを効率的にオフロードできるため、iptablesベースの従来の方法と比較してパフォーマンスとセキュリティが向上します。
|
||||
|
||||
実際には、CiliumとKube-OVNを簡単に[統合]((https://kube-ovn.readthedocs.io/zh-cn/stable/en/advance/with-cilium/))することが可能です。
|
||||
これにより、仮想マシン向けにシームレスでマルチテナントのネットワーキングを提供する統合ソリューションを実現することができます。
|
||||
また、高度なネットワークポリシーと統合されたサービスネットワーク機能も提供されます。
|
||||
|
||||
### 外部トラフィックのロードバランサー
|
||||
|
||||
この段階で、Kubernetes内で仮想マシンを実行するために必要なものはすべて揃っています。
|
||||
しかし、実際にはもう1つ必要なものがあります。
|
||||
クラスターの外部からサービスにアクセスする必要がまだあり、外部ロードバランサーがこれを整理するのに役立ちます。
|
||||
|
||||
ベアメタルのKubernetesクラスターには、いくつかの利用可能なロードバランサーがあります。
|
||||
[MetalLB](https://metallb.universe.tf/)、[kube-vip](https://kube-vip.io/)、[LoxiLB](https://www.loxilb.io/)があり、また[Cilium](https://docs.cilium.io/en/latest/network/lb-ipam/)と[Kube-OVN](https://kube-ovn.readthedocs.io/zh-cn/latest/en/guide/loadbalancer-service/)にはビルトインの実装が提供されています。
|
||||
|
||||
外部ロードバランサーの役割は、外部から利用可能な安定したアドレスを提供し、外部トラフィックをサービスネットワークに誘導することです。
|
||||
サービスネットワークプラグインは、通常どおりそれをPodと仮想マシンに誘導します。
|
||||
|
||||
{{< figure src="net-loadbalancer.svg" caption="Kubernetesのネットワーク構成における外部ロードバランサーの役割を示す図" alt="Kubernetesのネットワーク構成における外部ロードバランサーの役割" >}}
|
||||
|
||||
ほとんどの場合、ベアメタル上でのロードバランサーの設定は、クラスター内のノードにフローティングIPアドレスを作成し、ARP/NDPまたはBGPプロトコルを使用してそれを外部にアナウンスすることによって実現されます。
|
||||
|
||||
さまざまなオプションを検討した結果、MetalLBが最もシンプルで信頼性の高いソリューションであると判断しましたが、MetalLBの使用のみを厳密に強制しているわけではありません。
|
||||
|
||||
もう1つの利点は、L2モードでは、MetalLBスピーカーがメンバーリストプロトコルを使用してライブネスチェックを実行することにより、ネイバーの状態を継続的にチェックすることです。
|
||||
これにより、Kubernetesコントロールプレーンとは独立して機能するフェイルオーバーが可能になります。
|
||||
|
||||
## まとめ
|
||||
|
||||
ここまでが、Kubernetesにおける仮想化、ストレージ、ネットワークの概要になります。
|
||||
ここで取り上げたテクノロジーは、[Cozystack](https://github.com/aenix-io/cozystack)プラットフォームで利用可能であり、制限なくお試しいただけるよう事前に設定されています。
|
||||
|
||||
[次の記事](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-3/)では、この上にボタンをクリックするだけで、完全に機能するKubernetesクラスターのプロビジョニングをどのように実装できるかを詳しく説明します。
|
||||
|
|
@ -0,0 +1,207 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート3)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-3
|
||||
date: 2024-04-05T07:40:00+00:00
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Daiki Hayakawa(bells17)](https://github.com/bells17) ([3-shake Inc.](https://3-shake.com/en/)), [atoato88](https://github.com/atoato88) ([NEC Corporation](https://jpn.nec.com/index.html))
|
||||
|
||||
Kubernetesの中でKubernetesを実行するという最も興味深いフェーズに近づいています。
|
||||
この記事では、KamajiやCluster APIなどのテクノロジーとそれらのKubeVirtとの統合について説明します。
|
||||
|
||||
以前の議論では、[ベアメタル上でのKubernetesの準備](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/)と、[Kubernetesを仮想マシン管理システムに変える方法](/ja/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-2)について説明しました。
|
||||
この記事では、上記のすべてを使用して、本格的な管理対象のKubernetesを構築し、ワンクリックで仮想Kubernetesクラスターを実行する方法を説明して、シリーズを締めくくります。
|
||||
|
||||
まず、Cluster APIについて詳しく見ていきましょう。
|
||||
|
||||
## Cluster API
|
||||
|
||||
Cluster APIは、Kubernetesの拡張機能で、別のKubernetesクラスター内でカスタムリソースとしてKubernetesクラスターを管理できるようにするものです。
|
||||
|
||||
Cluster APIの主な目的は、Kubernetesクラスターの基本的なエンティティを記述し、そのライフサイクルを管理するための統一されたインターフェースを提供することです。
|
||||
これにより、クラスターの作成、更新、削除のプロセスを自動化し、スケーリングとインフラストラクチャの管理を簡素化できます。
|
||||
|
||||
Cluster APIのコンテキストでは、**管理クラスター**と**テナントクラスター**の2つの用語があります。
|
||||
|
||||
- **管理クラスター**は、他のクラスターのデプロイと管理に使用されるKubernetesクラスターです。
|
||||
このクラスターには、必要なすべてのCluster APIコンポーネントが含まれており、テナントクラスターの記述、作成、更新を担当します。多くの場合、この目的でのみ使用されます。
|
||||
- **テナントクラスター**は、ユーザークラスターまたはCluster APIを使用してデプロイされたクラスターです。
|
||||
これらは、管理クラスターで関連するリソースを記述することで作成されます。その後、エンドユーザーがアプリケーションとサービスをデプロイするために使用されます。
|
||||
|
||||
テナントクラスターは、物理的に管理クラスターと同じインフラストラクチャ上で実行する必要は必ずしもないことを理解することが重要です。
|
||||
むしろ多くの場合、それらは別の場所で実行されています。
|
||||
|
||||
{{< figure src="clusterapi1.svg" caption="Cluster APIを使用した管理KubernetesクラスターとテナントKubernetesクラスターの相互作用を示す図" alt="Cluster APIを使用した管理KubernetesクラスターとテナントKubernetesクラスターの相互作用を示す図" >}}
|
||||
|
||||
Cluster APIは、その動作のために _プロバイダー_ の概念を利用します。
|
||||
プロバイダーは、作成されるクラスターの特定のコンポーネントを担当する個別のコントローラーです。
|
||||
Cluster API内にはいくつかの種類のプロバイダーがあります。
|
||||
主なものは次のとおりです。
|
||||
|
||||
- **インフラストラクチャプロバイダー**: 仮想マシンや物理サーバーなどのコンピューティングインフラストラクチャを提供する役割を担います。
|
||||
- **コントロールプレーンプロバイダー**: kube-apiserver、kube-scheduler、kube-controller-managerなどのKubernetesコントロールプレーンを提供します。
|
||||
- **ブートストラッププロバイダー**: 作成される仮想マシンやサーバー用のcloud-init設定の生成に使用されます。
|
||||
|
||||
始めるには、Cluster API自体と各種プロバイダーを1つずつインストールする必要があります。
|
||||
サポートされているプロバイダーの完全なリストはプロジェクトの[ドキュメント](https://cluster-api.sigs.k8s.io/reference/providers.html)で確認できます。
|
||||
|
||||
インストールには`clusterctl`ユーティリティや、より宣言的な方法として[Cluster API Operator](https://github.com/kubernetes-sigs/cluster-api-operator)を使用できます。
|
||||
|
||||
## プロバイダーの選択
|
||||
|
||||
### インフラストラクチャプロバイダー
|
||||
|
||||
KubeVirtを使用してKubernetesクラスターを実行するには[KubeVirt Infrastructure Provider](https://github.com/kubernetes-sigs/cluster-api-provider-kubevirt)をインストールする必要があります。
|
||||
これにより、Cluster APIが動作する管理クラスターと同じ場所で、ワーカーノード用の仮想マシンをデプロイできるようになります。
|
||||
|
||||
### コントロールプレーンプロバイダー
|
||||
|
||||
[Kamaji](https://github.com/clastix/kamaji)プロジェクトは、管理クラスター内のコンテナとしてテナントクラスターのKubernetesコントロールプレーンを実行するためのソリューションを提供しています。
|
||||
このアプローチには、いくつかの重要な利点があります。
|
||||
|
||||
- **費用対効果**: コントロールプレーンをコンテナで実行することで、クラスターごとに個別のコントロールプレーンノードを使用する必要がなくなり、インフラストラクチャのコストを大幅に削減できます。
|
||||
- **安定性**: 複雑な多層デプロイメント方式を排除することでアーキテクチャを簡素化できます。
|
||||
仮想マシンを順次起動してからその中にetcdとKubernetesコンポーネントをインストールするのではなく、Kubernetes内で通常のアプリケーションとしてデプロイおよび実行され、オペレーターによって管理されるシンプルなコントロールプレーンがあります。
|
||||
- **セキュリティ**: クラスターのコントロールプレーンはエンドユーザーから隠されており、そのコンポーネントが侵害される可能性を減らし、クラスターの証明書ストアへのユーザーアクセスを排除します。ユーザーに見えないコントロールプレーンを構成するこのアプローチは、クラウドプロバイダーによって頻繁に使用されています。
|
||||
|
||||
### ブートストラッププロバイダー
|
||||
|
||||
[Kubeadm](https://github.com/kubernetes-sigs/cluster-api/tree/main/bootstrap)をブートストラッププロバイダーとして使用します。
|
||||
これは、Cluster APIでクラスターを準備するための標準的な方法です。
|
||||
このプロバイダーは、Cluster API自体の一部として開発されています。kubeletとkubeadmがインストールされた準備済みのシステムイメージのみが必要で、cloud-initとignitionの形式でコンフィグを生成できます。
|
||||
|
||||
Talos LinuxもCluster API経由でのプロビジョニングをサポートしており、そのための[プロバイダー](https://github.com/siderolabs/cluster-api-bootstrap-provider-talos)が[用意されている](https://github.com/siderolabs/cluster-api-bootstrap-provider-talos)ことは注目に値します。
|
||||
[前回の記事](/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/)では、ベアメタルノードで管理クラスターをセットアップするためにTalos Linuxを使用する方法について説明しましたが、テナントクラスターをプロビジョニングするには、Kamaji+Kubeadmのアプローチの方が優れています。
|
||||
コンテナへのKubernetesコントロールプレーンのデプロイを容易にするため、コントロールプレーンインスタンス用に個別の仮想マシンを用意する必要無くなります。
|
||||
これにより、管理が簡素化され、コストが削減されます。
|
||||
|
||||
## 動作の仕組み
|
||||
|
||||
Cluster APIの主要なオブジェクトはClusterリソースで、他のすべてのリソースの親となります。
|
||||
通常、このリソースは他の2つのリソースを参照します。
|
||||
**コントロールプレーン**を記述するリソースと**インフラストラクチャ**を記述するリソースです。
|
||||
それぞれが個別のプロバイダーによって管理されます。
|
||||
|
||||
Clusterとは異なり、これら2つのリソースは標準化されておらず、そのリソースの種類は使用している特定のプロバイダーに依存します。
|
||||
|
||||
{{< figure src="clusterapi2.svg" caption="Cluster APIにおけるClusterリソースとそれがリンクするリソースの関係を示す図" alt="Cluster APIにおけるClusterリソースとそれがリンクするリソースの関係を示す図" >}}
|
||||
|
||||
Cluster APIには、MachineDeploymentという名前のリソースもあります。
|
||||
これは物理サーバーか仮想マシンかにかかわらずノードのグループを記述するものです。
|
||||
このリソースは、Deployment、ReplicaSet、Podなどの標準のKubernetesリソースと同様に機能し、ノードのグループを宣言的に記述し、自動的にスケーリングするためのメカニズムを提供します。
|
||||
|
||||
つまり、MachineDeploymentリソースを使用すると、クラスターのノードを宣言的に記述でき、指定されたパラメーターと要求されたレプリカ数に応じて、ノードの作成、削除、更新を自動化できます。
|
||||
|
||||
{{< figure src="machinedeploymentres.svg" caption="Cluster APIにおけるMachineDeploymentリソースとその子リソースの関係を示す図" alt="Cluster APIにおけるClusterリソースとその子リソースの関係を示す図" >}}
|
||||
|
||||
マシンを作成するために、MachineDeploymentは、マシン自体を生成するためのテンプレートと、そのcloud-init設定を生成するためのテンプレートを参照します。
|
||||
|
||||
{{< figure src="clusterapi3.svg" caption="Cluster APIにおけるMachineDeploymentリソースとそれがリンクするリソースの関係を示す図" alt="Cluster APIにおけるClusterリソースとそれがリンクするリソースの関係を示す図" >}}
|
||||
|
||||
Cluster APIを使用して新しいKubernetesクラスターをデプロイするには、以下のリソースのセットを準備する必要があります。
|
||||
|
||||
- 一般的なClusterリソース
|
||||
- Kamajiが運用するコントロールプレーンを担当するKamajiControlPlaneリソース
|
||||
- KubeVirt内のクラスター設定を記述するKubevirtClusterリソース
|
||||
- 仮想マシンテンプレートを担当するKubevirtMachineTemplateリソース
|
||||
- トークンとcloud-initの生成を担当するKubeadmConfigTemplateリソース
|
||||
- いくつかのワーカーを作成するための少なくとも1つのMachineDeployment
|
||||
|
||||
## クラスターの仕上げ
|
||||
|
||||
ほとんどの場合これで十分ですが、使用するプロバイダーによっては、他のリソースも必要になる場合があります。
|
||||
プロバイダーの種類ごとに作成されるリソースの例は、[Kamajiプロジェクトのドキュメント](https://github.com/clastix/cluster-api-control-plane-provider-kamaji?tab=readme-ov-file#-supported-capi-infrastructure-providers)で確認できます。
|
||||
|
||||
この段階ですでに使用可能なテナントKubernetesクラスターができていますが、これまでのところ、APIワーカーとあらゆるKubernetesクラスターのインストールに標準で含まれるいくつかのコアプラグイン(**kube-proxy**と**CoreDNS**)しか含まれていません。
|
||||
完全に統合するには、さらにいくつかのコンポーネントをインストールする必要があります。
|
||||
|
||||
追加のコンポーネントをインストールするには、個別の[Cluster API Add-on Provider for Helm](https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm)や、[前の記事](/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/)で説明した[FluxCD](https://fluxcd.io/)を使用できます。
|
||||
|
||||
FluxCDでリソースを作成する際、Cluster APIによって生成されたkubeconfigを参照することでターゲットクラスターを指定できます。
|
||||
そうするとインストールは直接そのクラスターに対して実行されます。
|
||||
このように、FluxCDは管理クラスターとユーザーテナントクラスターの両方でリソースを管理するための汎用ツールになります。
|
||||
|
||||
{{< figure src="fluxcd.svg" caption="管理クラスターとテナントKubernetesクラスターの両方にコンポーネントをインストールできるfluxcdの相互作用スキームを示す図" alt="管理クラスターとテナントKubernetesクラスターの両方にコンポーネントをインストールできるfluxcdの相互作用スキームを示す図" >}}
|
||||
|
||||
ここで議論されているコンポーネントとは何でしょうか？一般的に、そのセットには以下が含まれます。
|
||||
|
||||
### CNIプラグイン
|
||||
|
||||
テナントKubernetesクラスター内のPod間の通信を確保するには、CNIプラグインをデプロイする必要があります。
|
||||
このプラグインは、Pod同士が相互に通信できるようにする仮想ネットワークを作成し、従来はクラスターのワーカーノード上にDaemonsetとしてデプロイされます。
|
||||
適切だと思うCNIプラグインを選んでインストールできます。
|
||||
|
||||
{{< figure src="components1.svg" caption="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスター内にインストールされたCNIプラグインを示す図" alt="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスター内にインストールされたCNIプラグインを示す図" >}}
|
||||
|
||||
### クラウドコントローラーマネージャー
|
||||
|
||||
この一部レスポンスについては、以下のようにMarkdown記法を修正するのが良いと思います。
|
||||
|
||||
クラウドコントローラーマネージャー(CCM)の主な役割は、Kubernetes をクラウドインフラストラクチャプロバイダーの環境(この場合は、テナントKubernetesのすべてのワーカーがプロビジョニングされている管理Kubernetesクラスター)と統合することです。
|
||||
CCMが実行するタスクは次のとおりです。
|
||||
|
||||
1. LoadBalancer タイプのサービスが作成されると、CCM はクラウドロードバランサーの作成プロセスを開始します。これにより、トラフィックが Kubernetes クラスターに誘導されます。
|
||||
2. クラウドインフラストラクチャからノードが削除された場合、CCM はクラスターからもそのノードを確実に削除し、クラスターの現在の状態を維持します。
|
||||
3. CCM を使用する場合、ノードは特別な taint (`node.cloudprovider.kubernetes.io/uninitialized`) を付けてクラスターに追加されます。これにより、必要に応じて追加のビジネスロジックを処理できます。初期化が正常に完了すると、この taint がノードから削除されます。
|
||||
|
||||
クラウドプロバイダーによっては、CCM がテナントクラスターの内部と外部の両方で動作する場合があります。
|
||||
|
||||
[KubeVirt Cloud Provider](https://github.com/kubevirt/cloud-provider-kubevirt)は、外部の親管理クラスターにインストールするように設計されています。
|
||||
したがって、テナントクラスターでLoadBalancerタイプのサービスを作成すると親クラスターでLoadBalancerサービスの作成が開始され、トラフィックがテナントクラスターに誘導されます。
|
||||
|
||||
{{< figure src="components2.svg" caption="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCloud Controller Managerと、それが管理する親から子へのKubernetesクラスター間のサービスのマッピングを示す図" alt="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCloud Controller Managerと、それが管理する親から子へのKubernetesクラスター間のサービスのマッピングを示す図" >}}
|
||||
|
||||
### CSIドライバー
|
||||
|
||||
Container Storage Interface(CSI)は、Kubernetesでストレージを操作するために、2つの主要な部分に分かれています。
|
||||
|
||||
- **csi-controller**: このコンポーネントは、クラウドプロバイダーのAPIと対話して、ボリュームの作成、削除、アタッチ、デタッチ、およびサイズ変更を行う責任があります。
|
||||
- **csi-node**: このコンポーネントは各ノードで実行され、kubeletから要求されたPodへのボリュームのマウントを容易にします。
|
||||
|
||||
[KubeVirt CSI Driver](https://github.com/kubevirt/csi-driver)を使用するコンテキストでは、ユニークな機会が生まれます。
|
||||
KubeVirtの仮想マシンは管理KubernetesクラスターでKubernetesのフル機能のAPIが利用できる環境で実行されるため、ユーザーのテナントクラスターの外部でcsi-controllerを実行する道が開かれます。
|
||||
このアプローチはKubeVirtコミュニティで人気があり、いくつかの重要な利点があります。
|
||||
|
||||
- **セキュリティ**: この方法では、エンドユーザーからクラウドの内部APIを隠し、Kubernetesインターフェースを介してのみリソースへのアクセスを提供します。これにより、ユーザークラスターから管理クラスターへの直接アクセスのリスクが軽減されます。
|
||||
- **シンプルさと利便性**: ユーザーは自分のクラスターで追加のコントローラーを管理する必要がないため、アーキテクチャが簡素化され、管理の負担が軽減されます。
|
||||
|
||||
ただし、csi-nodeは、各ノードのkubeletと直接やり取りするため、必然的にテナントクラスター内で実行する必要があります。
|
||||
このコンポーネントは、Podへのボリュームのマウントとマウント解除を担当し、クラスターノードで直接発生するプロセスとの緊密な統合が必要です。
|
||||
|
||||
KubeVirt CSIドライバーは、ボリュームの要求のためのプロキシとして機能します。
|
||||
テナントクラスター内でPVCが作成されると、管理クラスターにPVCが作成され、作成されたPVが仮想マシンに接続されます。
|
||||
|
||||
{{< figure src="components3.svg" caption="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの内部と外部の両方にインストールされたCSIプラグインのコンポーネントと、それが管理する親から子へのKubernetesクラスター間の永続ボリュームのマッピングを示す図" alt="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの内部と外部の両方にインストールされたCSIプラグインのコンポーネントと、それが管理する親から子へのKubernetesクラスター間の永続ボリュームのマッピングを示す図" >}}
|
||||
|
||||
### クラスターオートスケーラー
|
||||
|
||||
[クラスターオートスケーラー](https://github.com/kubernetes/autoscaler)は、さまざまなクラウドAPIと連携できる汎用的なコンポーネントであり、Cluster APIとの統合は利用可能な機能の1つに過ぎません。
|
||||
適切に設定するには、2つのクラスターへのアクセスが必要です。
|
||||
テナントクラスターではPodを追跡し、新しいノードを追加する必要性を判断し、管理するKubernetesクラスター(管理Kubernetesクラスター)ではMachineDeploymentリソースと対話し、レプリカ数を調整します。
|
||||
|
||||
Cluster Autoscalerは通常テナントKubernetesクラスター内で実行されますが、今回のケースでは、前述と同じ理由からクラスター外にインストールすることをお勧めします。
|
||||
このアプローチは、テナントクラスターのユーザーが管理クラスターの管理APIにアクセスできないようにするため、メンテナンスがより簡単で、より安全です。
|
||||
|
||||
{{< figure src="components4.svg" caption="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCluster Autoscalerを示す図" alt="ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCloud Controller Managerを示す図" >}}
|
||||
|
||||
### Konnectivity
|
||||
|
||||
もう1つ追加のコンポーネントについて言及したいと思います。
|
||||
[Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/)です。
|
||||
後でテナントKubernetesクラスターでwebhookとAPIアグリゲーションレイヤーを動作させるために、おそらくこれが必要になるでしょう。
|
||||
このトピックについては、私の[以前の記事](/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/#webhooks-and-api-aggregation-layer)で詳しく説明しています。
|
||||
|
||||
上記のコンポーネントとは異なり、Kamajiでは、Konnectivityを簡単に有効にし、kube-proxyやCoreDNSと並んで、テナントクラスターのコアコンポーネントの1つとして管理できます。
|
||||
|
||||
## まとめ
|
||||
|
||||
これで、動的スケーリング、ボリュームの自動プロビジョニング、ロードバランサーの機能を備えた、完全に機能するKubernetesクラスターができました。
|
||||
|
||||
今後は、テナントクラスターからのメトリクスやログの収集を検討するとよいでしょうが、それはこの記事の範囲を超えています。
|
||||
|
||||
もちろん、Kubernetesクラスターをデプロイするために必要なコンポーネントはすべて、1つのHelmチャートにパッケージ化し、統一されたアプリケーションとしてデプロイできます。
|
||||
これは、オープンなPaaSプラットフォームである[Cozystack](https://cozystack.io/)で、ボタンをクリックするだけで管理対象のKubernetesクラスターのデプロイを整理する方法そのものです。
|
||||
Cozystackでは、記事で説明したすべてのテクノロジーを無料で試すことができます。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "SIG Nodeの紹介"
|
||||
slug: sig-node-spotlight-2024
|
||||
canonicalUrl: https://www.kubernetes.dev/blog/2024/06/20/sig-node-spotlight-2024
|
||||
date: 2024-06-20
|
||||
author: >
|
||||
Arpit Agrawal
|
||||
---
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
|
||||
|
||||
コンテナオーケストレーションの世界で、[Kubernetes](/ja)は圧倒的な存在感を示しており、世界中で最も複雑で動的なアプリケーションの一部を動かしています。
|
||||
その裏では、Special Interest Groups(SIG)のネットワークがKubernetesの革新と安定性を牽引しています。
|
||||
|
||||
今日は、SIG Nodeのメンバーである[Matthias Bertschy](https://www.linkedin.com/in/matthias-bertschy-b427b815/)、[Gunju Kim](https://www.linkedin.com/in/gunju-kim-916b33190/)、[Sergey Kanzhelev](https://www.linkedin.com/in/sergeykanzhelev/)にお話を伺い、彼らの役割、課題、そして[SIG Node](https://github.com/kubernetes/community/blob/master/sig-node/README.md)内の注目すべき取り組みについて光を当てていきます。
|
||||
|
||||
_複数の回答者による共同回答の場合は、回答者全員のイニシャルで表記します。_
|
||||
|
||||
## 自己紹介
|
||||
|
||||
**Arpit:** 本日はお時間をいただき、ありがとうございます。まず、自己紹介とSIG Node内での役割について簡単に教えていただけますか？
|
||||
|
||||
**Matthias:** Matthias Bertschyと申します。フランス人で、フランスアルプスの近く、ジュネーブ湖のそばに住んでいます。2017年からKubernetesのコントリビューターとして活動し、SIG Nodeのレビュアー、そして[Prow](https://docs.prow.k8s.io/docs/overview/)のメンテナーを務めています。現在は、[ARMO](https://www.armosec.io/)というセキュリティスタートアップでシニアKubernetes開発者として働いています。ARMOは、[Kubescape](https://www.cncf.io/projects/kubescape/)というプロジェクトをCNCFに寄贈しました。
|
||||
|
||||
|
||||
|
||||
**Gunju:** Gunju Kimと申します。[NAVER](https://www.navercorp.com/naver/naverMain)でソフトウェアエンジニアとして働いており、検索サービス用のクラウドプラットフォームの開発に注力しています。2021年から空き時間を使ってKubernetesプロジェクトにコントリビュートしています。
|
||||
|
||||
**Sergey:** Sergey Kanzhelevと申します。3年間Kubernetesと[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine)に携わり、長年オープンソースプロジェクトに取り組んできました。現在はSIG Nodeの議長を務めています。
|
||||
|
||||
## SIG Nodeについて
|
||||
|
||||
**Arpit:** ありがとうございます！Kubernetesエコシステム内でのSIG Nodeの責任について、読者の方々に概要を説明していただけますか？
|
||||
|
||||
**M/G/S:** SIG NodeはKubernetesで最初に、あるいは最初期に設立されたSIGの1つです。このSIGは、KubernetesとNodeリソースとのすべてのやり取り、そしてNode自体のメンテナンスに責任を持っています。これはかなり広範囲に及び、SIGはKubernetesのコードベースの大部分を所有しています。この広範な所有権のため、SIG NodeはSIG Network、SIG Storage、SIG Securityなど他のSIGと常に連絡を取り合っており、Kubernetesの新機能や開発のほとんどが何らかの形でSIG Nodeに関わっています。
|
||||
|
||||
**Arpit**: SIG NodeはKubernetesのパフォーマンスと安定性にどのように貢献していますか？
|
||||
|
||||
**M/G/S:** Kubernetesは、安価なハードウェアを搭載した小型の物理VMから、大規模なAI/ML最適化されたGPU搭載Nodeまで、さまざまなサイズと形状のNodeで動作します。Nodeは数か月オンラインのままの場合もあれば、クラウドプロバイダーの余剰コンピューティングで実行されているため、短命で任意のタイミングでプリエンプトされる可能性もあります。
|
||||
|
||||
Node上のKubernetesエージェントである[`kubelet`](/ja/docs/concepts/overview/components/#kubelet)は、これらすべての環境で確実に動作する必要があります。
|
||||
近年、`kubelet`の操作パフォーマンスの重要性が増しています。
|
||||
その理由は二つあります。
|
||||
一つは、Kubernetesが通信や小売業などの分野で、より小規模なNodeで使用されるようになってきており、可能な限り小さなリソース消費(フットプリント)で動作することが求められているからです。
|
||||
もう一つは、AI/MLワークロードでは各Nodeが非常に高価なため、操作の遅延がわずか1秒でも計算コストに大きな影響を与える可能性があるからです。
|
||||
|
||||
## 課題と機会
|
||||
|
||||
**Arpit:** SIG Nodeが今後直面すると予想される課題や可能性について、どのようなものがあるでしょうか？
|
||||
|
||||
**M/G/S:** Kubernetesが誕生から10年を迎え、次の10年に向かう中で、新しい種類のワークロードへの対応が強く求められています。SIG Nodeはこの取り組みで重要な役割を果たすことになるでしょう。後ほど詳しく説明しますが、サイドカーのKEPは、こうした新しいタイプのワークロードをサポートするための取り組みの一例です。
|
||||
|
||||
今後数年間の主な課題は、既存の機能の品質と後方互換性を維持しつつ、いかに革新を続けていくかということです。
|
||||
SIG Nodeは、これからもKubernetesの開発において中心的な役割を担い続けるでしょう。
|
||||
|
||||
**Arpit:** SIG Nodeで現在取り組んでいる研究や開発分野の中で、特に注目しているものはありますか？
|
||||
|
||||
**M/G/S:** 新しいタイプのワークロードへの対応は、私たちにとって非常に興味深い分野です。最近取り組んでいるサイドカーコンテナの研究はその好例といえるでしょう。サイドカーは、アプリケーションの中核となるコードを変更することなく、その機能を拡張できる柔軟なソリューションを提供します。
|
||||
|
||||
**Arpit:** SIG Nodeを維持する上で直面した課題と、それをどのように克服したかを教えてください。
|
||||
|
||||
**M/G/S:** SIG Nodeが直面する最大の課題は、その広範な責任範囲と数多くの機能要望への対応です。この課題に取り組むため、私たちは新たなレビュアーの参加を積極的に呼びかけています。また、常にプロセスの改善に努め、フィードバックに迅速に対応できる体制を整えています。さらに、各リリースの後にはSIG Nodeのミーティングでフィードバックセッションを開催し、問題点や改善が必要な分野を特定し、具体的な行動計画を立てています。
|
||||
|
||||
**Arpit:** SIG Nodeが現在注目している技術や、Kubernetesへの導入を検討している新しい機能などはありますか？
|
||||
|
||||
**M/G/S:** SIG Nodeは、Kubernetesが依存しているさまざまなコンポーネントの開発に積極的に関与し、その進展を注意深く見守っています。これには、[コンテナランタイム]((/ja/docs/setup/production-environment/container-runtimes/))([containerd](https://containerd.io/)や[CRI-O](https://cri-o.io/)など)やOSの機能が含まれます。例えば、現在 _cgroup v1_ の廃止と削除が迫っていますが、これに対してKubernetesユーザーが円滑に移行できるよう、SIG NodeとKubernetesプロジェクト全体で取り組んでいます。また、containerdがバージョン`2.0`をリリースする予定ですが、これには非推奨機能の削除が含まれており、Kubernetesユーザーにも影響が及ぶと考えられます。
|
||||
|
||||
**Arpit:** SIG Nodeのメンテナーとしての経験の中で、特に誇りに思う思い出深い経験や成果を共有していただけますか？
|
||||
|
||||
**Mathias:** 最高の瞬間は、私の最初のKEP([`startupProbe`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)の導入)がついにGA(General Availability)に昇格したときだと思います。また、私の貢献がコントリビューターによって日々使用されているのを見るのも楽しいです。例えば、スカッシュコミットにもかかわらずLGTMを保持するために使用されるGitHubツリーハッシュを含むコメントなどです。
|
||||
|
||||
## サイドカーコンテナ
|
||||
|
||||
**Arpit:** Kubernetesの文脈におけるサイドカーコンテナの概念とその進化について、もう少し詳しく教えていただけますか？
|
||||
|
||||
**M/G/S:** [サイドカーコンテナ](/ja/docs/concepts/workloads/pods/sidecar-containers/)の概念は、Kubernetesが複合コンテナのアイデアを導入した2015年にさかのぼります。同じPod内でメインのアプリケーションコンテナと並行して実行されるこれらの追加コンテナは、コアのコードベースを変更することなくアプリケーションの機能を拡張・強化する方法として見られていました。サイドカーの初期の採用者はカスタムスクリプトと設定を使用して管理していましたが、このアプローチは一貫性とスケーラビリティの面で課題がありました。
|
||||
|
||||
**Arpit:** サイドカーコンテナが特に有益な具体的なユースケースや例を共有していただけますか？
|
||||
|
||||
**M/G/S:** サイドカーコンテナは、さまざまな方法でアプリケーションの機能を強化するために使用できる多用途なツールです:
|
||||
|
||||
- **ロギングとモニタリング:** サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナからログとメトリクスを収集し、中央のロギングおよびモニタリングシステムに送信できます。
|
||||
- **トラフィックのフィルタリングとルーティング:** サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナとの間のトラフィックをフィルタリングおよびルーティングできます。
|
||||
- **暗号化と復号化:** サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナと外部サービスの間で流れるデータを暗号化および復号化できます。
|
||||
- **データ同期:** サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナと外部データベースやサービスの間でデータを同期できます。
|
||||
- **フォールトインジェクション:** サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナに障害を注入し、障害に対する耐性をテストできます。
|
||||
|
||||
**Arpit:** 提案によると、一部の企業がサイドカー機能を追加したKubernetesのフォークを使用しているそうです。この機能の採用状況やコミュニティの関心度について、何か見解をお聞かせいただけますか？
|
||||
|
||||
**M/G/S:** 採用率を測定する具体的な指標はありませんが、KEPはコミュニティから大きな関心を集めています。特にIstioのようなサービスメッシュベンダーは、アルファテストフェーズに積極的に参加しました。KEPの可視性は、多数のブログ投稿、インタビュー、講演、ワークショップを通じてさらに実証されています。KEPは、ネットワークプロキシ、ロギングシステム、セキュリティ対策など、KubernetesのPod内のメインコンテナと並行して追加機能を提供する需要の増加に対応しています。コミュニティは、この機能の広範な採用を促進するために、既存のワークロードに対する容易な移行パスを提供することの重要性を認識しています。
|
||||
|
||||
**Arpit:** 本番環境でサイドカーコンテナを使用している企業の注目すべき例や成功事例はありますか？
|
||||
|
||||
**M/G/S:** 本番環境での広範な採用を期待するにはまだ早すぎます。1.29リリースは2024年1月11日からGoogle Kubernetes Engine(GKE)で利用可能になったばかりで、ユニバーサルインジェクターを介して効果的に有効化し使用する方法に関する包括的なドキュメントがまだ必要です。人気のあるサービスメッシュプラットフォームであるIstioも、ネイティブサイドカーを有効にするための適切なドキュメントが不足しているため、開発者がこの新機能を使い始めるのが難しくなっています。しかし、ネイティブサイドカーのサポートが成熟し、ドキュメントが改善されるにつれて、本番環境でのこの技術のより広範な採用が期待できます。
|
||||
|
||||
**Arpit:** 提案では、サイドカー機能を実現するために初期化したコンテナに`restartPolicy`フィールドを導入することが示されています。この方法で、先ほど挙げられた課題をどのように解決できるのか、詳しく教えていただけますか？
|
||||
|
||||
**M/G/S:** 初期化したコンテナに`restartPolicy`フィールドを導入する提案は、既存のインフラストラクチャを活用し、サイドカーの管理を簡素化することで、概説された課題に対処します。このアプローチは、Podの仕様に新しいフィールドを追加することを避け、管理しやすさを保ちつつ、さらなる複雑さを回避します。既存の初期化したコンテナのメカニズムを利用することで、サイドカーはPodの起動時に通常の初期化コンテナと並行して実行でき、一貫した初期化の順序を確保します。ささらに、サイドカー用の初期化コンテナの再起動ポリシーを`Always`に設定することで、メインアプリケーションコンテナが終了した後も、ロギングやモニタリングなどの継続的なサービスをワークロードの終了まで維持できます。
|
||||
|
||||
**Arpit:** 初期化したコンテナに`restartPolicy`フィールドを導入することは、既存のKubernetes設定との後方互換性にどのような影響を与えますか？
|
||||
|
||||
**M/G/S:** 初期化したコンテナに`restartPolicy`フィールドを導入しても、既存のKubernetes設定との後方互換性は維持されます。既存の初期化したコンテナは従来通りに機能し続け、新しい`restartPolicy`フィールドは、明示的にサイドカーとして指定された初期化したコンテナにのみ適用されます。このアプローチにより、既存のアプリケーションやデプロイメントが新機能によって中断されることはなく、同時にサイドカーをより効果的に定義および管理する方法が提供されます。
|
||||
|
||||
## SIG Nodeへの貢献
|
||||
|
||||
**Arpit:** 新しいメンバー、特に初心者が貢献するのに最適な方法は何でしょうか？
|
||||
|
||||
**M/G/S:** 新しいメンバーや初心者は、サイドカーに関するKEP(Kubernetes Enhancement Proposal)に対して、以下の方法で貢献できます:
|
||||
|
||||
- **認知度の向上:** サイドカーの利点と使用例を紹介するコンテンツを作成します。これにより、他の人々にこの機能の理解を深めてもらい、採用を促すことができます。
|
||||
- **フィードバックの提供:** サイドカーの使用経験(良い点も悪い点も)を共有してください。このフィードバックは、機能の改善や使いやすさの向上に役立ちます。
|
||||
- **ユースケースの共有:** 本番環境でサイドカーを使用している場合は、その経験を他の人と共有してください。実際の使用例を示すことで、この機能の価値を実証し、他の人々の採用を促進できます。
|
||||
- **ドキュメントの改善:** この機能のドキュメントの明確化や拡充にご協力ください。より分かりやすいドキュメントは、他の人々がサイドカーを理解し、活用する助けになります。
|
||||
|
||||
サイドカーに関するKEP以外にも、SIG Nodeではより多くの貢献者を必要としている分野があります:
|
||||
|
||||
- **テストカバレッジの向上:** SIG Nodeでは、Kubernetesコンポーネントのテストカバレッジを継続的に改善する方法を模索しています。
|
||||
|
||||
- **CI(継続的インテグレーション)の維持:** SIG Nodeは、Kubernetesコンポーネントが様々な状況下で期待通りに動作することを確認するため、一連のエンドツーエンド(e2e)テストを管理しています。
|
||||
|
||||
# 結論
|
||||
|
||||
SIG Nodeは、Kubernetesの発展において重要な役割を果たしています。
|
||||
クラウドネイティブ・コンピューティングの絶えず変化する環境の中で、Kubernetesの信頼性と適応性を確保し続けています。
|
||||
Matthias、Gunju、Sergeyといった献身的なメンバーが先頭に立ち、SIG Nodeは革新の最前線に立ち続けています。
|
||||
彼らの努力により、Kubernetesは新たな地平を目指して前進し続けているのです。
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: ノードリソースマネージャー
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
レイテンシーが致命的なワークロードや高スループットのワークロードをサポートするために、Kubernetesは一連のリソースマネージャーを提供します。リソースマネージャーはCPUやデバイス、メモリ(hugepages)などのリソースの特定の要件が設定されたPodのためにノードリソースの調整と最適化を目指しています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
メインのマネージャーであるトポロジーマネージャーは[ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)に沿って全体のリソース管理プロセスを調整するKubeletコンポーネントです。
|
||||
|
||||
個々のマネージャーの設定は下記のドキュメントで詳しく説明されてます。
|
||||
|
||||
- [CPUマネージャーポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)
|
||||
- [デバイスポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
|
||||
- [メモリマネージャーポリシー](/docs/tasks/administer-cluster/memory-manager/)
|
||||
|
|
@ -5,6 +5,7 @@ metadata:
|
|||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Użycie Deploymentu to rekomendowana metoda zarządzania tworzeniem i skalowanie
|
|||
wykorzystując podany obraz Dockera.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=808
|
||||
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
|
||||
```
|
||||
|
||||
2. Sprawdź stan Deploymentu:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,221 @@
|
|||
---
|
||||
title: 集群自动扩缩容
|
||||
linkTitle: 集群自动扩缩容
|
||||
description: >-
|
||||
自动管理集群中的节点以适配需求。
|
||||
content_type: concept
|
||||
weight: 120
|
||||
---
|
||||
<!--
|
||||
title: Cluster Autoscaling
|
||||
linkTitle: Cluster Autoscaling
|
||||
description: >-
|
||||
Automatically manage the nodes in your cluster to adapt to demand.
|
||||
content_type: concept
|
||||
weight: 120
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Kubernetes requires {{< glossary_tooltip text="nodes" term_id="node" >}} in your cluster to
|
||||
run {{< glossary_tooltip text="pods" term_id="pod" >}}. This means providing capacity for
|
||||
the workload Pods and for Kubernetes itself.
|
||||
|
||||
You can adjust the amount of resources available in your cluster automatically:
|
||||
_node autoscaling_. You can either change the number of nodes, or change the capacity
|
||||
that nodes provide. The first approach is referred to as _horizontal scaling_, while the
|
||||
second is referred to as _vertical scaling_.
|
||||
|
||||
Kubernetes can even provide multidimensional automatic scaling for nodes.
|
||||
-->
|
||||
Kubernetes 需要集群中的{{< glossary_tooltip text="节点" term_id="node" >}}来运行
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}。
|
||||
这意味着需要为工作负载 Pod 以及 Kubernetes 本身提供容量。
|
||||
|
||||
你可以自动调整集群中可用的资源量：**节点自动扩缩容**。
|
||||
你可以更改节点的数量，或者更改节点提供的容量。
|
||||
第一种方法称为**水平扩缩容**，而第二种方法称为**垂直扩缩容**。
|
||||
|
||||
Kubernetes 甚至可以为节点提供多维度的自动扩缩容。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Manual node management
|
||||
|
||||
You can manually manage node-level capacity, where you configure a fixed amount of nodes;
|
||||
you can use this approach even if the provisioning (the process to set up, manage, and
|
||||
decommission) for these nodes is automated.
|
||||
|
||||
This page is about taking the next step, and automating management of the amount of
|
||||
node capacity (CPU, memory, and other node resources) available in your cluster.
|
||||
-->
|
||||
## 手动节点管理 {#manual-node-management}
|
||||
|
||||
你可以手动管理节点级别的容量，例如你可以配置固定数量的节点；
|
||||
即使这些节点的制备（搭建、管理和停用过程）是自动化的，你也可以使用这种方法。
|
||||
|
||||
本文介绍的是下一步操作，即自动化管理集群中可用的节点容量（CPU、内存和其他节点资源）。
|
||||
|
||||
<!--
|
||||
## Automatic horizontal scaling {#autoscaling-horizontal}
|
||||
|
||||
### Cluster Autoscaler
|
||||
|
||||
You can use the [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) to manage the scale of your nodes automatically.
|
||||
The cluster autoscaler can integrate with a cloud provider, or with Kubernetes'
|
||||
[cluster API](https://github.com/kubernetes/autoscaler/blob/c6b754c359a8563050933a590f9a5dece823c836/cluster-autoscaler/cloudprovider/clusterapi/README.md),
|
||||
to achieve the actual node management that's needed.
|
||||
-->
|
||||
## 自动水平扩缩容 {#autoscaling-horizontal}
|
||||
|
||||
### Cluster Autoscaler
|
||||
|
||||
你可以使用 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)
|
||||
自动管理节点的数目规模。Cluster Autoscaler 可以与云驱动或 Kubernetes 的
|
||||
[Cluster API](https://github.com/kubernetes/autoscaler/blob/c6b754c359a8563050933a590f9a5dece823c836/cluster-autoscaler/cloudprovider/clusterapi/README.md)
|
||||
集成，以完成实际所需的节点管理。
|
||||
|
||||
<!--
|
||||
The cluster autoscaler adds nodes when there are unschedulable Pods, and
|
||||
removes nodes when those nodes are empty.
|
||||
|
||||
#### Cloud provider integrations {#cluster-autoscaler-providers}
|
||||
|
||||
The [README](https://github.com/kubernetes/autoscaler/tree/c6b754c359a8563050933a590f9a5dece823c836/cluster-autoscaler#readme)
|
||||
for the cluster autoscaler lists some of the cloud provider integrations
|
||||
that are available.
|
||||
-->
|
||||
当存在不可调度的 Pod 时，Cluster Autoscaler 会添加节点；
|
||||
当这些节点为空时，Cluster Autoscaler 会移除节点。
|
||||
|
||||
#### 云驱动集成组件 {#cluster-autoscaler-providers}
|
||||
|
||||
Cluster Autoscaler 的
|
||||
[README](https://github.com/kubernetes/autoscaler/tree/c6b754c359a8563050933a590f9a5dece823c836/cluster-autoscaler#readme)
|
||||
列举了一些可用的云驱动集成组件。
|
||||
|
||||
<!--
|
||||
## Cost-aware multidimensional scaling {#autoscaling-multi-dimension}
|
||||
|
||||
### Karpenter {#autoscaler-karpenter}
|
||||
|
||||
[Karpenter](https://karpenter.sh/) supports direct node management, via
|
||||
plugins that integrate with specific cloud providers, and can manage nodes
|
||||
for you whilst optimizing for overall cost.
|
||||
-->
|
||||
## 成本感知多维度扩缩容 {#autoscaling-multi-dimension}
|
||||
|
||||
### Karpenter {#autoscaler-karpenter}
|
||||
|
||||
[Karpenter](https://karpenter.sh/) 支持通过继承了特定云驱动的插件来直接管理节点，
|
||||
还可以在优化总体成本的同时为你管理节点。
|
||||
|
||||
<!--
|
||||
> Karpenter automatically launches just the right compute resources to
|
||||
> handle your cluster's applications. It is designed to let you take
|
||||
> full advantage of the cloud with fast and simple compute provisioning
|
||||
> for Kubernetes clusters.
|
||||
-->
|
||||
> Karpenter 自动启动适合你的集群应用的计算资源。
|
||||
> Karpenter 设计为让你充分利用云资源，快速简单地为 Kubernetes 集群制备计算资源。
|
||||
|
||||
<!--
|
||||
The Karpenter tool is designed to integrate with a cloud provider that
|
||||
provides API-driven server management, and where the price information for
|
||||
available servers is also available via a web API.
|
||||
|
||||
For example, if you start some more Pods in your cluster, the Karpenter
|
||||
tool might buy a new node that is larger than one of the nodes you are
|
||||
already using, and then shut down an existing node once the new node
|
||||
is in service.
|
||||
-->
|
||||
Karpenter 工具设计为与云驱动集成，提供 API 驱动的服务器管理，
|
||||
此工具可以通过 Web API 获取可用服务器的价格信息。
|
||||
|
||||
例如，如果你在集群中启动更多 Pod，Karpenter 工具可能会购买一个比你当前使用的节点更大的新节点，
|
||||
然后在这个新节点投入使用后关闭现有的节点。
|
||||
|
||||
<!--
|
||||
#### Cloud provider integrations {#karpenter-providers}
|
||||
-->
|
||||
#### 云驱动集成组件 {#karpenter-providers}
|
||||
|
||||
{{% thirdparty-content vendor="true" %}}
|
||||
|
||||
<!--
|
||||
There are integrations available between Karpenter's core and the following
|
||||
cloud providers:
|
||||
|
||||
- [Amazon Web Services](https://github.com/aws/karpenter-provider-aws)
|
||||
- [Azure](https://github.com/Azure/karpenter-provider-azure)
|
||||
-->
|
||||
在 Karpenter 的核心与以下云驱动之间，存在可用的集成组件：
|
||||
|
||||
- [Amazon Web Services](https://github.com/aws/karpenter-provider-aws)
|
||||
- [Azure](https://github.com/Azure/karpenter-provider-azure)
|
||||
|
||||
<!--
|
||||
## Related components
|
||||
|
||||
### Descheduler
|
||||
|
||||
The [descheduler](https://github.com/kubernetes-sigs/descheduler) can help you
|
||||
consolidate Pods onto a smaller number of nodes, to help with automatic scale down
|
||||
when the cluster has space capacity.
|
||||
-->
|
||||
## 相关组件 {#related-components}
|
||||
|
||||
### Descheduler
|
||||
|
||||
[Descheduler](https://github.com/kubernetes-sigs/descheduler)
|
||||
可以帮助你将 Pod 集中到少量节点上，以便在集群有空闲容量时帮助自动缩容。
|
||||
|
||||
<!--
|
||||
### Sizing a workload based on cluster size
|
||||
|
||||
#### Cluster proportional autoscaler
|
||||
|
||||
For workloads that need to be scaled based on the size of the cluster (for example
|
||||
`cluster-dns` or other system components), you can use the
|
||||
[_Cluster Proportional Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).<br />
|
||||
|
||||
The Cluster Proportional Autoscaler watches the number of schedulable nodes
|
||||
and cores, and scales the number of replicas of the target workload accordingly.
|
||||
-->
|
||||
### 基于集群大小调整工作负载 {#sizing-a-workload-based-on-cluster-size}
|
||||
|
||||
#### Cluster Proportional Autoscaler
|
||||
|
||||
对于需要基于集群大小进行扩缩容的工作负载（例如 `cluster-dns` 或其他系统组件），
|
||||
你可以使用 [Cluster Proportional Autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)。
|
||||
|
||||
Cluster Proportional Autoscaler 监视可调度节点和核心的数量，并相应地调整目标工作负载的副本数量。
|
||||
|
||||
<!--
|
||||
#### Cluster proportional vertical autoscaler
|
||||
|
||||
If the number of replicas should stay the same, you can scale your workloads vertically according to the cluster size using
|
||||
the [_Cluster Proportional Vertical Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler).
|
||||
This project is in **beta** and can be found on GitHub.
|
||||
|
||||
While the Cluster Proportional Autoscaler scales the number of replicas of a workload, the Cluster Proportional Vertical Autoscaler
|
||||
adjusts the resource requests for a workload (for example a Deployment or DaemonSet) based on the number of nodes and/or cores
|
||||
in the cluster.
|
||||
-->
|
||||
#### Cluster Proportional Vertical Autoscaler
|
||||
|
||||
如果副本数量应该保持不变，你可以使用
|
||||
[Cluster Proportional Vertical Autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler)
|
||||
基于集群大小垂直扩缩你的工作负载。此项目处于 **Beta** 阶段，托管在 GitHub 上。
|
||||
|
||||
Cluster Proportional Autoscaler 扩缩工作负载的副本数量，而 Cluster Proportional Vertical Autoscaler
|
||||
基于集群中的节点和/或核心数量调整工作负载（例如 Deployment 或 DaemonSet）的资源请求。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- Read about [workload-level autoscaling](/docs/concepts/workloads/autoscaling/)
|
||||
-->
|
||||
- 参阅[工作负载级别自动扩缩容](/zh-cn/docs/concepts/workloads/autoscaling/)
|
||||
|
|
@ -1,5 +1,11 @@
|
|||
---
|
||||
title: "配置"
|
||||
weight: 80
|
||||
description: Kubernetes 为配置 Pods 提供的资源。
|
||||
description: Kubernetes 为配置 Pod 所提供的资源。
|
||||
---
|
||||
<!--
|
||||
title: "Configuration"
|
||||
weight: 80
|
||||
description: >
|
||||
Resources that Kubernetes provides for configuring Pods.
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
title: 存活、就绪和启动探针
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
title: Liveness, Readiness, and Startup Probes
|
||||
content_type: concept
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Kubernetes has various types of probes:
|
||||
|
||||
- [Liveness probe](#liveness-probe)
|
||||
- [Readiness probe](#readiness-probe)
|
||||
- [Startup probe](#startup-probe)
|
||||
-->
|
||||
Kubernetes 提供了多种探针：
|
||||
|
||||
- [存活探针](#liveness-probe)
|
||||
- [就绪探针](#readiness-probe)
|
||||
- [启动探针](#startup-probe)
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Liveness probe
|
||||
|
||||
Liveness probes determine when to restart a container. For example, liveness probes could catch a deadlock, when an application is running, but unable to make progress.
|
||||
-->
|
||||
## 存活探针 {#liveness-probe}
|
||||
|
||||
存活探针决定何时重启容器。
|
||||
例如，当应用在运行但无法取得进展时，存活探针可以捕获这类死锁。
|
||||
|
||||
<!--
|
||||
If a container fails its liveness probe repeatedly, the kubelet restarts the container.
|
||||
-->
|
||||
如果一个容器的存活探针失败多次，kubelet 将重启该容器。
|
||||
|
||||
<!--
|
||||
Liveness probes do not wait for readiness probes to succeed. If you want to wait before
|
||||
executing a liveness probe you can either define `initialDelaySeconds`, or use a
|
||||
[startup probe](#startup-probe).
|
||||
-->
|
||||
存活探针不会等待就绪探针成功。
|
||||
如果你想在执行存活探针前等待，你可以定义 `initialDelaySeconds`，或者使用[启动探针](#startup-probe)。
|
||||
|
||||
<!--
|
||||
## Readiness probe
|
||||
|
||||
Readiness probes determine when a container is ready to start accepting traffic. This is useful when waiting for an application to perform time-consuming initial tasks, such as establishing network connections, loading files, and warming caches.
|
||||
-->
|
||||
## 就绪探针 {#readiness-probe}
|
||||
|
||||
就绪探针决定何时容器准备好开始接受流量。
|
||||
这种探针在等待应用执行耗时的初始任务时非常有用，例如建立网络连接、加载文件和预热缓存。
|
||||
|
||||
<!--
|
||||
If the readiness probe returns a failed state, Kubernetes removes the pod from all matching service endpoints.
|
||||
|
||||
Readiness probes runs on the container during its whole lifecycle.
|
||||
-->
|
||||
如果就绪探针返回的状态为失败，Kubernetes 会将该 Pod 从所有对应服务的端点中移除。
|
||||
|
||||
就绪探针在容器的整个生命期内持续运行。
|
||||
|
||||
<!--
|
||||
## Startup probe
|
||||
|
||||
A startup probe verifies whether the application within a container is started. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running.
|
||||
-->
|
||||
## 启动探针 {#startup-probe}
|
||||
|
||||
启动探针检查容器内的应用是否已启动。
|
||||
启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被 kubelet 杀掉。
|
||||
|
||||
<!--
|
||||
If such a probe is configured, it disables liveness and readiness checks until it succeeds.
|
||||
-->
|
||||
如果配置了这类探针，它会禁用存活检测和就绪检测，直到启动探针成功为止。
|
||||
|
||||
<!--
|
||||
This type of probe is only executed at startup, unlike readiness probes, which are run periodically.
|
||||
|
||||
* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).
|
||||
-->
|
||||
这类探针仅在启动时执行，不像就绪探针那样周期性地运行。
|
||||
|
||||
* 更多细节参阅[配置存活、就绪和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes)。
|
||||
|
|
@ -157,7 +157,7 @@ document.
|
|||
如果没有使用 `Accept` 头指示资源类型，对于 `/api` 和 `/apis` 端点的默认响应将是一个非聚合的发现文档。
|
||||
|
||||
<!--
|
||||
The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2.json)
|
||||
The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json)
|
||||
for the built-in resources can be found in the Kubernetes GitHub repository.
|
||||
This Github document can be used as a reference of the base set of the available resources
|
||||
if a Kubernetes cluster is not available to query.
|
||||
|
|
|
|||
|
|
@ -1111,7 +1111,7 @@ The following operators can only be used with `nodeAffinity`.
|
|||
以下操作符只能与 `nodeAffinity` 一起使用。
|
||||
|
||||
<!--
|
||||
| Operator | Behaviour |
|
||||
| Operator | Behavior |
|
||||
| :------------: | :-------------: |
|
||||
| `Gt` | The field value will be parsed as an integer, and that integer is less than the integer that results from parsing the value of a label named by this selector |
|
||||
| `Lt` | The field value will be parsed as an integer, and that integer is greater than the integer that results from parsing the value of a label named by this selector |
|
||||
|
|
@ -1135,7 +1135,7 @@ are not available for `podAffinity`.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
|
||||
- Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
- Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
|
||||
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
|
||||
- Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
|
||||
|
|
|
|||
|
|
@ -7,7 +7,8 @@ description: Kubernetes 网络背后的概念和资源。
|
|||
<!--
|
||||
## The Kubernetes network model
|
||||
|
||||
Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address.
|
||||
Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address
|
||||
(one address per IP address family).
|
||||
This means you do not need to explicitly create links between `Pods` and you
|
||||
almost never need to deal with mapping container ports to host ports.
|
||||
This creates a clean, backwards-compatible model where `Pods` can be treated
|
||||
|
|
@ -18,7 +19,7 @@ application configuration, and migration.
|
|||
## Kubernetes 网络模型 {#the-kubernetes-network-model}
|
||||
|
||||
集群中每一个 [`Pod`](/zh-cn/docs/concepts/workloads/pods/) 都会获得自己的、
|
||||
独一无二的 IP 地址，
|
||||
独一无二的 IP 地址（每个 IP 地址族一个地址），
|
||||
这就意味着你不需要显式地在 `Pod` 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。
|
||||
这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、
|
||||
[负载均衡](/zh-cn/docs/concepts/services-networking/ingress/#load-balancing)、
|
||||
|
|
@ -41,11 +42,9 @@ Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排
|
|||
* 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信
|
||||
|
||||
<!--
|
||||
Note: For those platforms that support `Pods` running in the host network (e.g.
|
||||
Linux), when pods are attached to the host network of a node they can still communicate
|
||||
with all pods on all nodes without NAT.
|
||||
For those platforms that support `Pods` running in the host network (such as Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT.
|
||||
-->
|
||||
说明：对于支持在主机网络中运行 `Pod` 的平台（比如：Linux），
|
||||
对于支持在主机网络中运行 `Pod` 的平台（比如：Linux），
|
||||
当 Pod 挂接到节点的宿主网络上时，它们仍可以不通过 NAT 和所有节点上的 Pod 通信。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -179,16 +179,16 @@ Service 的地址族默认为第一个服务集群 IP 范围的地址族（通
|
|||
using the first configured service cluster IP range.
|
||||
* `PreferDualStack`:Allocates both IPv4 and IPv6 cluster IPs for the Service when dual-stack is enabled. If dual-stack is not enabled or supported, it falls back to single-stack behavior.
|
||||
* `RequireDualStack`: Allocates Service `.spec.clusterIPs` from both IPv4 and IPv6 address ranges when dual-stack is enabled. If dual-stack is not enabled or supported, the Service API object creation fails.
|
||||
* Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family
|
||||
* Selects the `.spec.clusterIP` from the list of `.spec.clusterIPs` based on the address family
|
||||
of the first element in the `.spec.ipFamilies` array.
|
||||
-->
|
||||
* `SingleStack`：单栈 Service。控制面使用第一个配置的服务集群 IP 范围为 Service 分配集群 IP。
|
||||
* `PreferDualStack`：启用双栈时，为 Service 同时分配 IPv4 和 IPv6 集群 IP 地址。
|
||||
如果双栈未被启用或不被支持，则会返回到单栈行为。
|
||||
* `RequireDualStack`：启用双栈时，同时从 IPv4 和 IPv6 的地址范围中分配 Service 的 `.spec.ClusterIPs`。
|
||||
* `RequireDualStack`：启用双栈时，同时从 IPv4 和 IPv6 的地址范围中分配 Service 的 `.spec.clusterIPs`。
|
||||
如果双栈未被启用或不被支持，则 Service API 对象创建失败。
|
||||
* 从基于在 `.spec.ipFamilies` 数组中第一个元素的地址族的 `.spec.ClusterIPs`
|
||||
列表中选择 `.spec.ClusterIP`
|
||||
* 从基于在 `.spec.ipFamilies` 数组中第一个元素的地址族的 `.spec.clusterIPs`
|
||||
列表中选择 `.spec.clusterIP`
|
||||
|
||||
<!--
|
||||
If you would like to define which IP family to use for single stack or define the order of IP
|
||||
|
|
@ -224,9 +224,9 @@ You can set `.spec.ipFamilies` to any of the following array values:
|
|||
- `["IPv6","IPv4"]` （双栈）
|
||||
|
||||
<!--
|
||||
The first family you list is used for the legacy `.spec.ClusterIP` field.
|
||||
The first family you list is used for the legacy `.spec.clusterIP` field.
|
||||
-->
|
||||
你所列出的第一个地址族用于原来的 `.spec.ClusterIP` 字段。
|
||||
你所列出的第一个地址族用于原来的 `.spec.clusterIP` 字段。
|
||||
|
||||
<!--
|
||||
### Dual-stack Service configuration scenarios
|
||||
|
|
@ -262,13 +262,13 @@ These examples demonstrate the behavior of various dual-stack Service configurat
|
|||
1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When
|
||||
you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6
|
||||
addresses for the service. The control plane updates the `.spec` for the Service to record the IP
|
||||
address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned
|
||||
IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from
|
||||
`.spec.ClusterIPs`.
|
||||
address assignments. The field `.spec.clusterIPs` is the primary field, and contains both assigned
|
||||
IP addresses; `.spec.clusterIP` is a secondary field with its value calculated from
|
||||
`.spec.clusterIPs`.
|
||||
|
||||
* For the `.spec.ClusterIP` field, the control plane records the IP address that is from the
|
||||
* For the `.spec.clusterIP` field, the control plane records the IP address that is from the
|
||||
same address family as the first service cluster IP range.
|
||||
* On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list
|
||||
* On a single-stack cluster, the `.spec.clusterIPs` and `.spec.clusterIP` fields both only list
|
||||
one address.
|
||||
* On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy`
|
||||
behaves the same as `PreferDualStack`.
|
||||
|
|
@ -276,12 +276,12 @@ These examples demonstrate the behavior of various dual-stack Service configurat
|
|||
2. 此 Service 规约显式地将 `.spec.ipFamilyPolicy` 设置为 `PreferDualStack`。
|
||||
当你在双栈集群上创建此 Service 时，Kubernetes 会为此 Service 分配 IPv4 和 IPv6 地址。
|
||||
控制平面更新 Service 的 `.spec` 以记录 IP 地址分配。
|
||||
字段 `.spec.ClusterIPs` 是主要字段，包含两个分配的 IP 地址；`.spec.ClusterIP` 是次要字段，
|
||||
其取值从 `.spec.ClusterIPs` 计算而来。
|
||||
字段 `.spec.clusterIPs` 是主要字段，包含两个分配的 IP 地址；`.spec.clusterIP` 是次要字段，
|
||||
其取值从 `.spec.clusterIPs` 计算而来。
|
||||
|
||||
* 对于 `.spec.ClusterIP` 字段，控制面记录来自第一个服务集群 IP
|
||||
* 对于 `.spec.clusterIP` 字段，控制面记录来自第一个服务集群 IP
|
||||
范围对应的地址族的 IP 地址。
|
||||
* 对于单协议栈的集群，`.spec.ClusterIPs` 和 `.spec.ClusterIP` 字段都
|
||||
* 对于单协议栈的集群，`.spec.clusterIPs` 和 `.spec.clusterIP` 字段都
|
||||
仅仅列出一个地址。
|
||||
* 对于启用了双协议栈的集群，将 `.spec.ipFamilyPolicy` 设置为
|
||||
`RequireDualStack` 时，其行为与 `PreferDualStack` 相同。
|
||||
|
|
@ -291,13 +291,13 @@ These examples demonstrate the behavior of various dual-stack Service configurat
|
|||
<!--
|
||||
1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well
|
||||
as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and
|
||||
IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is
|
||||
the first element in the `.spec.ClusterIPs` array, overriding the default.
|
||||
IPv4 address in `.spec.clusterIPs`, `.spec.clusterIP` is set to the IPv6 address because that is
|
||||
the first element in the `.spec.clusterIPs` array, overriding the default.
|
||||
-->
|
||||
3. 下面的 Service 规约显式地在 `.spec.ipFamilies` 中指定 `IPv6` 和 `IPv4`，并将
|
||||
`.spec.ipFamilyPolicy` 设定为 `PreferDualStack`。
|
||||
当 Kubernetes 为 `.spec.ClusterIPs` 分配一个 IPv6 和一个 IPv4 地址时，
|
||||
`.spec.ClusterIP` 被设置成 IPv6 地址，因为它是 `.spec.ClusterIPs` 数组中的第一个元素，
|
||||
当 Kubernetes 为 `.spec.clusterIPs` 分配一个 IPv6 和一个 IPv4 地址时，
|
||||
`.spec.clusterIP` 被设置成 IPv6 地址，因为它是 `.spec.clusterIPs` 数组中的第一个元素，
|
||||
覆盖其默认值。
|
||||
|
||||
{{% code_sample file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" %}}
|
||||
|
|
@ -319,7 +319,7 @@ dual-stack.)
|
|||
1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are
|
||||
configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set
|
||||
`.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP
|
||||
will be stored in `.spec.ClusterIPs`.
|
||||
will be stored in `.spec.clusterIPs`.
|
||||
-->
|
||||
1. 在集群上启用双栈时，控制面会将现有 Service（无论是 `IPv4` 还是 `IPv6`）配置
|
||||
`.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies`
|
||||
|
|
@ -366,14 +366,14 @@ dual-stack.)
|
|||
[headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are
|
||||
configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set
|
||||
`.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the
|
||||
`--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to
|
||||
`--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.clusterIP` is set to
|
||||
`None`.
|
||||
-->
|
||||
2. 在集群上启用双栈时，带有选择算符的现有
|
||||
[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
|
||||
由控制面设置 `.spec.ipFamilyPolicy` 为 `SingleStack`
|
||||
并设置 `.spec.ipFamilies` 为第一个服务集群 IP 范围的地址族（通过配置 kube-apiserver 的
|
||||
`--service-cluster-ip-range` 参数），即使 `.spec.ClusterIP` 的设置值为 `None` 也如此。
|
||||
`--service-cluster-ip-range` 参数），即使 `.spec.clusterIP` 的设置值为 `None` 也如此。
|
||||
|
||||
{{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}}
|
||||
|
||||
|
|
@ -455,15 +455,15 @@ Service 可以从单栈更改为双栈，也可以从双栈更改为单栈。
|
|||
<!--
|
||||
1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from
|
||||
`PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from
|
||||
dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs`
|
||||
array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address
|
||||
family of `.spec.ClusterIPs`.
|
||||
dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.clusterIPs`
|
||||
array, and sets `.spec.clusterIP` to that IP address and sets `.spec.ipFamilies` to the address
|
||||
family of `.spec.clusterIPs`.
|
||||
-->
|
||||
2. 要将 Service 从双栈更改为单栈，请将 `.spec.ipFamilyPolicy` 从 `PreferDualStack` 或
|
||||
`RequireDualStack` 改为 `SingleStack`。
|
||||
当你将此 Service 从双栈更改为单栈时，Kubernetes 只保留 `.spec.ClusterIPs`
|
||||
数组中的第一个元素，并设置 `.spec.ClusterIP` 为那个 IP 地址，
|
||||
并设置 `.spec.ipFamilies` 为 `.spec.ClusterIPs` 地址族。
|
||||
当你将此 Service 从双栈更改为单栈时，Kubernetes 只保留 `.spec.clusterIPs`
|
||||
数组中的第一个元素，并设置 `.spec.clusterIP` 为那个 IP 地址，
|
||||
并设置 `.spec.ipFamilies` 为 `.spec.clusterIPs` 地址族。
|
||||
|
||||
<!--
|
||||
### Headless Services without selector
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/).
|
|||
[服务类型](#publishing-services-service-types)默认为 ClusterIP 的 Service。
|
||||
该 Service 指向带有标签 `app.kubernetes.io/name: MyApp` 的所有 Pod 的 TCP 端口 9376。
|
||||
|
||||
Kubernetes 为该服务分配一个 IP 地址（称为 “集群 IP”），供虚拟 IP 地址机制使用。
|
||||
Kubernetes 为该 Service 分配一个 IP 地址（称为 “集群 IP”），供虚拟 IP 地址机制使用。
|
||||
有关该机制的更多详情，请阅读[虚拟 IP 和服务代理](/zh-cn/docs/reference/networking/virtual-ips/)。
|
||||
|
||||
<!--
|
||||
|
|
@ -317,7 +317,7 @@ Each port definition can have the same `protocol`, or a different one.
|
|||
Service 的默认协议是 [TCP](/zh-cn/docs/reference/networking/service-protocols/#protocol-tcp)；
|
||||
你还可以使用其他[受支持的任何协议](/zh-cn/docs/reference/networking/service-protocols/)。
|
||||
|
||||
由于许多 Service 需要公开多个端口，所以 Kubernetes 为同一服务定义[多个端口](#multi-port-services)。
|
||||
由于许多 Service 需要公开多个端口，所以 Kubernetes 为同一 Service 定义[多个端口](#multi-port-services)。
|
||||
每个端口定义可以具有相同的 `protocol`，也可以具有不同协议。
|
||||
|
||||
<!--
|
||||
|
|
@ -408,14 +408,14 @@ endpoints:
|
|||
apiVersion: discovery.k8s.io/v1
|
||||
kind: EndpointSlice
|
||||
metadata:
|
||||
name: my-service-1 # 按惯例将服务的名称用作 EndpointSlice 名称的前缀
|
||||
name: my-service-1 # 按惯例将 Service 的名称用作 EndpointSlice 名称的前缀
|
||||
labels:
|
||||
# 你应设置 "kubernetes.io/service-name" 标签。
|
||||
# 设置其值以匹配服务的名称
|
||||
# 设置其值以匹配 Service 的名称
|
||||
kubernetes.io/service-name: my-service
|
||||
addressType: IPv4
|
||||
ports:
|
||||
- name: '' # 应与上面定义的服务端口的名称匹配
|
||||
- name: '' # 应与上面定义的 Service 端口的名称匹配
|
||||
appProtocol: http
|
||||
protocol: TCP
|
||||
port: 9376
|
||||
|
|
@ -539,7 +539,7 @@ See [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) for mo
|
|||
information about this API.
|
||||
-->
|
||||
[EndpointSlice](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
|
||||
对象表示某个服务的后端网络端点的子集（**切片**）。
|
||||
对象表示某个 Service 的后端网络端点的子集（**切片**）。
|
||||
|
||||
你的 Kubernetes 集群会跟踪每个 EndpointSlice 所表示的端点数量。
|
||||
如果 Service 的端点太多以至于达到阈值，Kubernetes 会添加另一个空的
|
||||
|
|
@ -737,14 +737,14 @@ Kubernetes Service 类型允许指定你所需要的 Service 类型。
|
|||
-->
|
||||
`ClusterIP`
|
||||
: 通过集群的内部 IP 公开 Service，选择该值时 Service 只能够在集群内部访问。
|
||||
这也是你没有为服务显式指定 `type` 时使用的默认值。
|
||||
这也是你没有为 Service 显式指定 `type` 时使用的默认值。
|
||||
你可以使用 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
|
||||
或者 [Gateway API](https://gateway-api.sigs.k8s.io/) 向公共互联网公开服务。
|
||||
|
||||
[`NodePort`](#type-nodeport)
|
||||
: 通过每个节点上的 IP 和静态端口（`NodePort`）公开 Service。
|
||||
为了让 Service 可通过节点端口访问，Kubernetes 会为 Service 配置集群 IP 地址，
|
||||
相当于你请求了 `type: ClusterIP` 的服务。
|
||||
相当于你请求了 `type: ClusterIP` 的 Service。
|
||||
|
||||
<!--
|
||||
[`LoadBalancer`](#loadbalancer)
|
||||
|
|
@ -775,7 +775,7 @@ define a `LoadBalancer` Service by
|
|||
-->
|
||||
服务 API 中的 `type` 字段被设计为层层递进的形式 - 每层都建立在前一层的基础上。
|
||||
但是，这种层层递进的形式有一个例外。
|
||||
你可以在定义 `LoadBalancer` 服务时[禁止负载均衡器分配 `NodePort`](/zh-cn/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)。
|
||||
你可以在定义 `LoadBalancer` Service 时[禁止负载均衡器分配 `NodePort`](/zh-cn/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)。
|
||||
|
||||
<!--
|
||||
### `type: ClusterIP` {#type-clusterip}
|
||||
|
|
@ -861,7 +861,7 @@ endpoints associated with that Service. You'll be able to contact the `type: Nod
|
|||
Service, from outside the cluster, by connecting to any node using the appropriate
|
||||
protocol (for example: TCP), and the appropriate port (as assigned to that Service).
|
||||
-->
|
||||
对于 NodePort 服务，Kubernetes 额外分配一个端口（TCP、UDP 或 SCTP 以匹配 Service 的协议）。
|
||||
对于 NodePort 类型 Service，Kubernetes 额外分配一个端口（TCP、UDP 或 SCTP 以匹配 Service 的协议）。
|
||||
集群中的每个节点都将自己配置为监听所分配的端口，并将流量转发到与该 Service 关联的某个就绪端点。
|
||||
通过使用合适的协议（例如 TCP）和适当的端口（分配给该 Service）连接到任何一个节点，
|
||||
你就能够从集群外部访问 `type: NodePort` 服务。
|
||||
|
|
@ -1300,7 +1300,7 @@ Select one of the tabs.
|
|||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
networking.gke.io/load-balancer-type: "Internal"
|
||||
networking.gke.io/load-balancer-type: "Internal"
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -1308,9 +1308,9 @@ metadata:
|
|||
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -1320,7 +1320,7 @@ metadata:
|
|||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
|
||||
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -1330,7 +1330,7 @@ metadata:
|
|||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
|
||||
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -1809,7 +1809,7 @@ Kubernetes 所配置的规则和路由会确保流量被路由到该 Service 的
|
|||
|
||||
定义 Service 时，你可以为任何[服务类型](#publishing-services-service-types)指定 `externalIPs`。
|
||||
|
||||
在下面的例子中，名为 `my-service` 的服务可以在 "`198.51.100.32:80`"
|
||||
在下面的例子中，名为 `my-service` 的 Service 可以在 "`198.51.100.32:80`"
|
||||
（根据 `.spec.externalIPs[]` 和 `.spec.ports[].port` 得出）上被客户端使用 TCP 协议访问。
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -0,0 +1,205 @@
|
|||
---
|
||||
title: 卷属性类
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- msau42
|
||||
- xing-yang
|
||||
title: Volume Attributes Classes
|
||||
content_type: concept
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.29" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
This page assumes that you are familiar with [StorageClasses](/docs/concepts/storage/storage-classes/),
|
||||
[volumes](/docs/concepts/storage/volumes/) and [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
in Kubernetes.
|
||||
-->
|
||||
本页假设你已经熟悉 Kubernetes 中的 [StorageClass](/zh-cn/docs/concepts/storage/storage-classes/)、
|
||||
[Volume](/zh-cn/docs/concepts/storage/volumes/) 和
|
||||
[PersistentVolume](/zh-cn/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
A VolumeAttributesClass provides a way for administrators to describe the mutable
|
||||
"classes" of storage they offer. Different classes might map to different quality-of-service levels.
|
||||
Kubernetes itself is unopinionated about what these classes represent.
|
||||
|
||||
This is an alpha feature and disabled by default.
|
||||
|
||||
If you want to test the feature whilst it's alpha, you need to enable the `VolumeAttributesClass`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-controller-manager and the kube-apiserver. You use the `--feature-gates` command line argument:
|
||||
-->
|
||||
卷属性类（VolumeAttributesClass）为管理员提供了一种描述可变更的存储“类”的方法。
|
||||
不同的类可以映射到不同的服务质量级别。Kubernetes 本身不关注这些类代表什么。
|
||||
|
||||
这是一个 Alpha 特性，默认被禁用。
|
||||
|
||||
如果你想测试这一处于 Alpha 阶段的特性，你需要为 kube-controller-manager 和 kube-apiserver 启用
|
||||
`VolumeAttributesClass` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
你可以使用 `--feature-gates` 命令行参数：
|
||||
|
||||
```
|
||||
--feature-gates="...,VolumeAttributesClass=true"
|
||||
```
|
||||
|
||||
<!--
|
||||
You can also only use VolumeAttributesClasses with storage backed by
|
||||
{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}, and only where the
|
||||
relevant CSI driver implements the `ModifyVolume` API.
|
||||
-->
|
||||
另外你只有在使用{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}支持的存储时才能使用
|
||||
VolumeAttributesClass，并且要求相关的 CSI 驱动实现了 `ModifyVolume` API。
|
||||
|
||||
<!--
|
||||
## The VolumeAttributesClass API
|
||||
|
||||
Each VolumeAttributesClass contains the `driverName` and `parameters`, which are
|
||||
used when a PersistentVolume (PV) belonging to the class needs to be dynamically provisioned
|
||||
or modified.
|
||||
|
||||
The name of a VolumeAttributesClass object is significant and is how users can request a particular class.
|
||||
Administrators set the name and other parameters of a class when first creating VolumeAttributesClass objects.
|
||||
While the name of a VolumeAttributesClass object in a `PersistentVolumeClaim` is mutable, the parameters in an existing class are immutable.
|
||||
-->
|
||||
## VolumeAttributesClass API {#the-volumeattributesclass-api}
|
||||
|
||||
每个 VolumeAttributesClass 都包含 `driverName` 和 `parameters` 字段，
|
||||
当属于此类的持久卷（PV）需要被动态制备或修改时系统会使用这两个字段。
|
||||
|
||||
VolumeAttributesClass 对象的名称比较重要，用户用对象名称来请求特定的类。
|
||||
管理员在首次创建 VolumeAttributesClass 对象时会设置某个类的名称和其他参数。
|
||||
虽然在 `PersistentVolumeClaim` 中 VolumeAttributesClass 对象的名称是可变的，
|
||||
但现有类中的参数是不可变的。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1alpha1
|
||||
kind: VolumeAttributesClass
|
||||
metadata:
|
||||
name: silver
|
||||
driverName: pd.csi.storage.gke.io
|
||||
parameters:
|
||||
provisioned-iops: "3000"
|
||||
provisioned-throughput: "50"
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
### Provisioner
|
||||
|
||||
Each VolumeAttributesClass has a provisioner that determines what volume plugin is used for provisioning PVs. The field `driverName` must be specified.
|
||||
|
||||
The feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
|
||||
-->
|
||||
### 存储制备器 {#provisioner}
|
||||
|
||||
每个 VolumeAttributesClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。
|
||||
`driverName` 字段是必填项。
|
||||
|
||||
针对 VolumeAttributesClass 的特性支持在
|
||||
[kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner) 中实现。
|
||||
|
||||
<!--
|
||||
You are not restricted to specifying the [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner). You can also run and specify external provisioners,
|
||||
which are independent programs that follow a specification defined by Kubernetes.
|
||||
Authors of external provisioners have full discretion over where their code lives, how
|
||||
the provisioner is shipped, how it needs to be run, what volume plugin it uses, etc.
|
||||
-->
|
||||
你并非必须指定 [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner)。
|
||||
你也可以运行并指定外部制备器，它们是遵循 Kubernetes 所定义的规范的独立程序。
|
||||
外部制备器的作者可以完全自行决定他们的代码放在哪儿、如何交付制备器、以何种方式运行、使用什么卷插件等。
|
||||
|
||||
<!--
|
||||
### Resizer
|
||||
|
||||
Each VolumeAttributesClass has a resizer that determines what volume plugin is used for modifying PVs. The field `driverName` must be specified.
|
||||
|
||||
The modifying volume feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer).
|
||||
|
||||
For example, a existing PersistentVolumeClaim is using a VolumeAttributesClass named silver:
|
||||
-->
|
||||
### 调整器 {#resizer}
|
||||
|
||||
每个 VolumeAttributesClass 都有一个调整器（Resizer），用于确定修改 PV 所用的卷插件。
|
||||
`driverName` 字段是必填项。
|
||||
|
||||
针对 VolumeAttributesClass 的修改卷特性支持在
|
||||
[kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer) 中实现。
|
||||
|
||||
如以下 YAML 所示，有一个 PersistentVolumeClaim 使用名为 silver 的 VolumeAttributesClass：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: test-pv-claim
|
||||
spec:
|
||||
…
|
||||
volumeAttributesClassName: silver
|
||||
…
|
||||
```
|
||||
|
||||
<!--
|
||||
A new VolumeAttributesClass gold is available in the cluster:
|
||||
-->
|
||||
集群中有一个新的名为 gold 的 VolumeAttributesClass：
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1alpha1
|
||||
kind: VolumeAttributesClass
|
||||
metadata:
|
||||
name: gold
|
||||
driverName: pd.csi.storage.gke.io
|
||||
parameters:
|
||||
iops: "4000"
|
||||
throughput: "60"
|
||||
```
|
||||
|
||||
<!--
|
||||
The end user can update the PVC with the new VolumeAttributesClass gold and apply:
|
||||
-->
|
||||
最终用户可以更新 PVC，使之使用新的名为 gold 的 VolumeAttributesClass，并应用此更新：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: test-pv-claim
|
||||
spec:
|
||||
…
|
||||
volumeAttributesClassName: gold
|
||||
…
|
||||
```
|
||||
|
||||
<!--
|
||||
## Parameters
|
||||
|
||||
VolumeAttributeClasses have parameters that describe volumes belonging to them. Different parameters may be accepted
|
||||
depending on the provisioner or the resizer. For example, the value `4000`, for the parameter `iops`,
|
||||
and the parameter `throughput` are specific to GCE PD.
|
||||
When a parameter is omitted, the default is used at volume provisioning.
|
||||
If a user apply the PVC with a different VolumeAttributesClass with omitted parameters, the default value of
|
||||
the parameters may be used depends on the CSI driver implementation.
|
||||
Please refer to the related CSI driver documentation for more details.
|
||||
-->
|
||||
## 参数 {#parameters}
|
||||
|
||||
VolumeAttributeClass 具有参数，用来描述隶属于该类的存储卷。可接受的参数可能因制备器或调整器而异。
|
||||
例如，参数 `iops` 的取值 `4000` 和参数 `throughput` 是特定于 GCE PD 的。
|
||||
如果某个参数被省略，则在卷制备时使用默认值。
|
||||
如果用户使用带有省略参数的不同 VolumeAttributesClass 来应用 PVC，参数的默认取值可能会因 CSI 驱动实现而异。
|
||||
有关细节参阅相关的 CSI 驱动文档。
|
||||
|
||||
<!--
|
||||
There can be at most 512 parameters defined for a VolumeAttributesClass.
|
||||
The total length of the parameters object including its keys and values cannot exceed 256 KiB.
|
||||
-->
|
||||
VolumeAttributesClass 最多可以定义 512 个参数。
|
||||
这些参数对象的总长度（包括其键和值）不能超过 256 KiB。
|
||||
|
|
@ -74,7 +74,7 @@ is healthy. For more information, please check
|
|||
当外部健康监测器检测到节点失效事件，控制器会报送一个事件，该事件会在 PVC 上继续上报，
|
||||
以表明使用此 PVC 的 Pod 正位于一个失效的节点上。
|
||||
|
||||
如果 CSI 驱动程序支持节点测的卷健康检测，那当在 CSI 卷上检测到异常卷时，
|
||||
如果 CSI 驱动程序支持节点侧的卷健康检测，那当在 CSI 卷上检测到异常卷时，
|
||||
会在使用该 PVC 的每个 Pod 上触发一个事件。
|
||||
此外，卷运行状况信息作为 Kubelet VolumeStats 指标公开。
|
||||
添加了一个新的指标 kubelet_volume_stats_health_status_abnormal。
|
||||
|
|
|
|||
|
|
@ -1,9 +1,11 @@
|
|||
---
|
||||
title: 卷
|
||||
api_metadata:
|
||||
- apiVersion: ""
|
||||
kind: "Volume"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- jsafrane
|
||||
|
|
@ -11,6 +13,9 @@ reviewers:
|
|||
- thockin
|
||||
- msau42
|
||||
title: Volumes
|
||||
api_metadata:
|
||||
- apiVersion: ""
|
||||
kind: "Volume"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
-->
|
||||
|
|
@ -117,15 +122,16 @@ Kubernetes supports several types of volumes.
|
|||
Kubernetes 支持下列类型的卷：
|
||||
|
||||
<!--
|
||||
### awsElasticBlockStore (removed) {#awselasticblockstore}
|
||||
### awsElasticBlockStore (deprecated) {#awselasticblockstore}
|
||||
-->
|
||||
### awsElasticBlockStore （已移除） {#awselasticblockstore}
|
||||
### awsElasticBlockStore （已弃用） {#awselasticblockstore}
|
||||
|
||||
<!-- maintenance note: OK to remove all mention of awsElasticBlockStore once the v1.27 release of
|
||||
Kubernetes has gone out of support -->
|
||||
|
||||
<!--
|
||||
Kubernetes {{< skew currentVersion >}} does not include a `awsElasticBlockStore` volume type.
|
||||
In Kubernetes {{< skew currentVersion >}}, all operations for the in-tree `awsElasticBlockStore` type
|
||||
are redirected to the `ebs.csi.aws.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver.
|
||||
|
||||
The AWSElasticBlockStore in-tree storage driver was deprecated in the Kubernetes v1.19 release
|
||||
and then removed entirely in the v1.27 release.
|
||||
|
|
@ -133,7 +139,8 @@ and then removed entirely in the v1.27 release.
|
|||
The Kubernetes project suggests that you use the [AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) third party
|
||||
storage driver instead.
|
||||
-->
|
||||
Kubernetes {{< skew currentVersion >}} 不包含 `awsElasticBlockStore` 卷类型。
|
||||
在 Kubernetes {{< skew currentVersion >}} 中，所有针对树内 `awsElasticBlockStore`
|
||||
类型的操作都会被重定向到 `ebs.csi.aws.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
|
||||
|
||||
AWSElasticBlockStore 树内存储驱动已在 Kubernetes v1.19 版本中废弃，
|
||||
并在 v1.27 版本中被完全移除。
|
||||
|
|
@ -142,15 +149,16 @@ Kubernetes 项目建议你转为使用 [AWS EBS](https://github.com/kubernetes-s
|
|||
第三方存储驱动插件。
|
||||
|
||||
<!--
|
||||
### azureDisk (removed) {#azuredisk}
|
||||
### azureDisk (deprecated) {#azuredisk}
|
||||
-->
|
||||
### azureDisk （已移除） {#azuredisk}
|
||||
### azureDisk （已弃用） {#azuredisk}
|
||||
|
||||
<!-- maintenance note: OK to remove all mention of azureDisk once the v1.27 release of
|
||||
Kubernetes has gone out of support -->
|
||||
|
||||
<!--
|
||||
Kubernetes {{< skew currentVersion >}} does not include a `azureDisk` volume type.
|
||||
In Kubernetes {{< skew currentVersion >}}, all operations for the in-tree `azureDisk` type
|
||||
are redirected to the `disk.csi.azure.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver.
|
||||
|
||||
The AzureDisk in-tree storage driver was deprecated in the Kubernetes v1.19 release
|
||||
and then removed entirely in the v1.27 release.
|
||||
|
|
@ -158,7 +166,8 @@ and then removed entirely in the v1.27 release.
|
|||
The Kubernetes project suggests that you use the [Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) third party
|
||||
storage driver instead.
|
||||
-->
|
||||
Kubernetes {{< skew currentVersion >}} 不包含 `azureDisk` 卷类型。
|
||||
在 Kubernetes {{< skew currentVersion >}} 中，所有针对树内 `azureDisk`
|
||||
类型的操作都会被重定向到 `disk.csi.azure.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
|
||||
|
||||
AzureDisk 树内存储驱动已在 Kubernetes v1.19 版本中废弃，并在 v1.27 版本中被完全移除。
|
||||
|
||||
|
|
@ -225,7 +234,10 @@ and the kubelet, set the `InTreePluginAzureFileUnregister` flag to `true`.
|
|||
要禁止控制器管理器和 kubelet 加载 `azureFile` 存储插件，
|
||||
请将 `InTreePluginAzureFileUnregister` 标志设置为 `true`。
|
||||
|
||||
### cephfs {#cephfs}
|
||||
<!--
|
||||
### cephfs (deprecated) {#cephfs}
|
||||
-->
|
||||
### cephfs（已弃用） {#cephfs}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.28" state="deprecated" >}}
|
||||
|
||||
|
|
@ -265,15 +277,16 @@ See the [CephFS example](https://github.com/kubernetes/examples/tree/master/volu
|
|||
更多信息请参考 [CephFS 示例](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)。
|
||||
|
||||
<!--
|
||||
### cinder (removed) {#cinder}
|
||||
### cinder (deprecated) {#cinder}
|
||||
-->
|
||||
### cinder（已移除） {#cinder}
|
||||
### cinder（已弃用） {#cinder}
|
||||
|
||||
<!-- maintenance note: OK to remove all mention of cinder once the v1.26 release of
|
||||
Kubernetes has gone out of support -->
|
||||
|
||||
<!--
|
||||
Kubernetes {{< skew currentVersion >}} does not include a `cinder` volume type.
|
||||
In Kubernetes {{< skew currentVersion >}}, all operations for the in-tree `cinder` type
|
||||
are redirected to the `cinder.csi.openstack.org` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver.
|
||||
|
||||
The OpenStack Cinder in-tree storage driver was deprecated in the Kubernetes v1.11 release
|
||||
and then removed entirely in the v1.26 release.
|
||||
|
|
@ -282,7 +295,8 @@ The Kubernetes project suggests that you use the
|
|||
[OpenStack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)
|
||||
third party storage driver instead.
|
||||
-->
|
||||
Kubernetes {{< skew currentVersion >}} 不包含 `cinder` 卷类型。
|
||||
在 Kubernetes {{< skew currentVersion >}} 中，所有针对树内 `cinder`
|
||||
类型的操作都会被重定向到 `cinder.csi.openstack.org` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
|
||||
|
||||
OpenStack Cinder 树内存储驱动已在 Kubernetes v1.11 版本中废弃，
|
||||
并在 v1.26 版本中被完全移除。
|
||||
|
|
@ -346,19 +360,20 @@ keyed with `log_level`.
|
|||
条目中的所有内容都被挂载到 Pod 的 `/etc/config/log_level` 路径下。
|
||||
请注意，这个路径来源于卷的 `mountPath` 和 `log_level` 键对应的 `path`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
* You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* You must [create a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-a-configmap)
|
||||
before you can use it.
|
||||
|
||||
* A ConfigMap is always mounted as `readOnly`.
|
||||
|
||||
* A container using a ConfigMap as a [`subPath`](#using-subpath) volume mount will not
|
||||
receive ConfigMap updates.
|
||||
|
||||
|
||||
* Text data is exposed as files using the UTF-8 character encoding. For other character encodings, use `binaryData`.
|
||||
-->
|
||||
{{< note >}}
|
||||
* 在使用 [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。
|
||||
* 你必须先[创建 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/#create-a-configmap)，
|
||||
才能使用它。
|
||||
* ConfigMap 总是以 `readOnly` 的模式挂载。
|
||||
* 容器以 [`subPath`](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。
|
||||
* 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用
|
||||
|
|
@ -455,15 +470,27 @@ overlays), the `emptyDir` may run out of capacity before this limit.
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If the `SizeMemoryBackedVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
|
||||
you can specify a size for memory backed volumes. If no size is specified, memory
|
||||
backed volumes are sized to node allocatable memory.
|
||||
You can specify a size for memory backed volumes, provided that the `SizeMemoryBackedVolumes`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is enabled in your cluster (this has been beta, and active by default, since the Kubernetes 1.22 release).
|
||||
If you don't specify a volume size, memory backed volumes are sized to node allocatable memory.
|
||||
-->
|
||||
当启用 `SizeMemoryBackedVolumes` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时，
|
||||
你可以为基于内存提供的卷指定大小。
|
||||
如果未指定大小，内存提供的卷的大小根据节点可分配内存进行调整。
|
||||
你可以指定内存作为介质的卷的大小，前提是集群中启用了 `SizeMemoryBackedVolumes`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
（自 Kubernetes 1.22 发布以来，此特性一直处于 Beta 阶段，并且默认启用）。
|
||||
如果你未指定大小，内存作为介质的卷的大小根据节点可分配内存进行调整。
|
||||
{{< /note>}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Please check [here](/docs/concepts/configuration/manage-resources-containers/#memory-backed-emptydir)
|
||||
for points to note in terms of resource management when using memory-backed `emptyDir`.
|
||||
-->
|
||||
使用内存作为介质的 `emptyDir` 卷时，
|
||||
请查阅[此处](/zh-cn/docs/concepts/configuration/manage-resources-containers/#memory-backed-emptydir)，
|
||||
了解有关资源管理方面的注意事项。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
#### emptyDir configuration example
|
||||
-->
|
||||
|
|
@ -517,13 +544,15 @@ for more details.
|
|||
更多详情请参考 [FC 示例](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)。
|
||||
|
||||
<!--
|
||||
### gcePersistentDisk (removed) {#gcepersistentdisk}
|
||||
### gcePersistentDisk (deprecated) {#gcepersistentdisk}
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} does not include a `gcePersistentDisk` volume type.
|
||||
In Kubernetes {{< skew currentVersion >}}, all operations for the in-tree `gcePersistentDisk` type
|
||||
are redirected to the `pd.csi.storage.gke.io` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver.
|
||||
-->
|
||||
### gcePersistentDisk（已移除） {#gcepersistentdisk}
|
||||
### gcePersistentDisk（已弃用） {#gcepersistentdisk}
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} 不包含 `gcePersistentDisk` 卷类型。
|
||||
在 Kubernetes {{< skew currentVersion >}} 中，所有针对树内 `gcePersistentDisk`
|
||||
类型的操作都会被重定向到 `pd.csi.storage.gke.io` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
|
||||
|
||||
<!--
|
||||
The `gcePersistentDisk` in-tree storage driver was deprecated in the Kubernetes v1.17 release
|
||||
|
|
@ -565,13 +594,34 @@ must be installed on the cluster.
|
|||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an
|
||||
[EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the
|
||||
The `gitRepo` volume type is deprecated.
|
||||
|
||||
To provision a Pod that has a Git repository mounted, you can
|
||||
mount an
|
||||
[`emptyDir`](#emptydir) volume into an [init container](/docs/concepts/workloads/pods/init-containers/) that
|
||||
clones the repo using Git, then mount the
|
||||
[EmptyDir](#emptydir) into the Pod's container.
|
||||
-->
|
||||
`gitRepo` 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个
|
||||
[EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git
|
||||
命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。
|
||||
`gitRepo` 卷类型已经被弃用。
|
||||
|
||||
如果需要制备已挂载 Git 仓库的 Pod，你可以将
|
||||
[EmptyDir](#emptydir) 卷挂载到 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/) 中，
|
||||
使用 Git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
You can restrict the use of `gitRepo` volumes in your cluster using
|
||||
[policies](/docs/concepts/policy/) such as
|
||||
[ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/).
|
||||
You can use the following Common Expression Language (CEL) expression as
|
||||
part of a policy to reject use of `gitRepo` volumes:
|
||||
`has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`.
|
||||
-->
|
||||
你可以使用 [ValidatingAdmissionPolicy](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)
|
||||
这类[策略](/zh-cn/docs/concepts/policy/)来限制在你的集群中使用 `gitRepo` 卷。
|
||||
你可以使用以下通用表达语言（CEL）表达式作为策略的一部分，以拒绝使用 `gitRepo` 卷：
|
||||
`has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -625,99 +675,138 @@ GlusterFS 树内存储驱动程序在 Kubernetes v1.25 版本中被弃用，然
|
|||
|
||||
### hostPath {#hostpath}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
HostPath volumes present many security risks, and it is a best practice to avoid the use of
|
||||
HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the
|
||||
required file or directory, and mounted as ReadOnly.
|
||||
|
||||
If restricting HostPath access to specific directories through AdmissionPolicy, `volumeMounts` MUST
|
||||
be required to use `readOnly` mounts for the policy to be effective.
|
||||
-->
|
||||
HostPath 卷存在许多安全风险，最佳做法是尽可能避免使用 HostPath。
|
||||
当必须使用 HostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。
|
||||
|
||||
如果通过 AdmissionPolicy 限制 HostPath 对特定目录的访问，则必须要求
|
||||
`volumeMounts` 使用 `readOnly` 挂载以使策略生效。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
A `hostPath` volume mounts a file or directory from the host node's filesystem
|
||||
into your Pod. This is not something that most Pods will need, but it offers a
|
||||
powerful escape hatch for some applications.
|
||||
-->
|
||||
`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。
|
||||
虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。
|
||||
虽然这不是大多数 Pod 需要的，但是它为一些应用提供了强大的逃生舱。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Using the `hostPath` volume type presents many security risks.
|
||||
If you can avoid using a `hostPath` volume, you should. For example,
|
||||
define a [`local` PersistentVolume](#local), and use that instead.
|
||||
|
||||
If you are restricting access to specific directories on the node using
|
||||
admission-time validation, that restriction is only effective when you
|
||||
additionally require that any mounts of that `hostPath` volume are
|
||||
**read only**. If you allow a read-write mount of any host path by an
|
||||
untrusted Pod, the containers in that Pod may be able to subvert the
|
||||
read-write host mount.
|
||||
-->
|
||||
使用 `hostPath` 类型的卷存在许多安全风险。如果可以，你应该尽量避免使用 `hostPath` 卷。
|
||||
例如，你可以改为定义并使用 [`local` PersistentVolume](#local)。
|
||||
|
||||
如果你通过准入时的验证来限制对节点上特定目录的访问，这种限制只有在你额外要求所有
|
||||
`hostPath` 卷的挂载都是**只读**的情况下才有效。如果你允许不受信任的 Pod 以读写方式挂载任意主机路径，
|
||||
则该 Pod 中的容器可能会破坏可读写主机挂载卷的安全性。
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
For example, some uses for a `hostPath` are:
|
||||
|
||||
* running a container that needs access to Docker internals; use a `hostPath`
|
||||
of `/var/lib/docker`
|
||||
* running cAdvisor in a container; use a `hostPath` of `/sys`
|
||||
* allowing a Pod to specify whether a given `hostPath` should exist prior to the
|
||||
Pod running, whether it should be created, and what it should exist as
|
||||
Take care when using `hostPath` volumes, whether these are mounted as read-only
|
||||
or as read-write, because:
|
||||
-->
|
||||
例如，`hostPath` 的一些用法有：
|
||||
|
||||
* 运行一个需要访问 Docker 内部机制的容器；可使用 `hostPath` 挂载 `/var/lib/docker` 路径。
|
||||
* 在容器中运行 cAdvisor 时，以 `hostPath` 方式挂载 `/sys`。
|
||||
* 允许 Pod 指定给定的 `hostPath` 在运行 Pod 之前是否应该存在，是否应该创建以及应该以什么方式存在。
|
||||
无论 `hostPath` 卷是以只读还是读写方式挂载，使用时都需要小心，这是因为：
|
||||
|
||||
<!--
|
||||
In addition to the required `path` property, you can optionally specify a `type` for a `hostPath` volume.
|
||||
|
||||
The supported values for field `type` are:
|
||||
* Access to the host filesystem can expose privileged system credentials (such as for the kubelet) or privileged APIs
|
||||
(such as the container runtime socket), that can be used for container escape or to attack other
|
||||
parts of the cluster.
|
||||
* Pods with identical configuration (such as created from a PodTemplate) may
|
||||
behave differently on different nodes due to different files on the nodes.
|
||||
* `hostPath` volume usage is not treated as ephemeral storage usage.
|
||||
You need to monitor the disk usage by yourself because excessive `hostPath` disk
|
||||
usage will lead to disk pressure on the node.
|
||||
-->
|
||||
除了必需的 `path` 属性之外，你可以选择性地为 `hostPath` 卷指定 `type`。
|
||||
* 访问主机文件系统可能会暴露特权系统凭证（例如 kubelet 的凭证）或特权 API（例如容器运行时套接字），
|
||||
这些可以被用于容器逃逸或攻击集群的其他部分。
|
||||
* 具有相同配置的 Pod（例如基于 PodTemplate 创建的 Pod）可能会由于节点上的文件不同而在不同节点上表现出不同的行为。
|
||||
* `hostPath` 卷的用量不会被视为临时存储用量。
|
||||
你需要自己监控磁盘使用情况，因为过多的 `hostPath` 磁盘使用量会导致节点上的磁盘压力。
|
||||
{{< /warning >}}
|
||||
|
||||
支持的 `type` 值如下：
|
||||
|
||||
<!--
|
||||
Some uses for a `hostPath` are:
|
||||
|
||||
* running a container that needs access to node-level system components
|
||||
(such as a container that transfers system logs to a central location,
|
||||
accessing those logs using a read-only mount of `/var/log`)
|
||||
* making a configuration file stored on the host system available read-only
|
||||
to a {{< glossary_tooltip text="static pod" term_id="static-pod" >}};
|
||||
unlike normal Pods, static Pods cannot access ConfigMaps
|
||||
-->
|
||||
`hostPath` 的一些用法有：
|
||||
|
||||
* 运行一个需要访问节点级系统组件的容器
|
||||
（例如一个将系统日志传输到集中位置的容器，使用只读挂载 `/var/log` 来访问这些日志）
|
||||
* 让存储在主机系统上的配置文件可以被{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}}
|
||||
以只读方式访问；与普通 Pod 不同，静态 Pod 无法访问 ConfigMap。
|
||||
|
||||
<!--
|
||||
#### `hostPath` volume types
|
||||
|
||||
In addition to the required `path` property, you can optionally specify a
|
||||
`type` for a `hostPath` volume.
|
||||
|
||||
The available values for `type` are:
|
||||
-->
|
||||
#### `hostPath` 卷类型
|
||||
|
||||
除了必需的 `path` 属性外，你还可以选择为 `hostPath` 卷指定 `type`。
|
||||
|
||||
`type` 的可用值有：
|
||||
|
||||
<!-- empty string represented using U+200C ZERO WIDTH NON-JOINER -->
|
||||
|
||||
<!--
|
||||
| Value | Behavior |
|
||||
|:------|:---------|
|
||||
| | Empty string (default) is for backward compatibility, which means that no checks will be performed before mounting the hostPath volume. |
|
||||
| `""` | Empty string (default) is for backward compatibility, which means that no checks will be performed before mounting the `hostPath` volume. |
|
||||
| `DirectoryOrCreate` | If nothing exists at the given path, an empty directory will be created there as needed with permission set to 0755, having the same group and ownership with Kubelet. |
|
||||
| `Directory` | A directory must exist at the given path |
|
||||
| `FileOrCreate` | If nothing exists at the given path, an empty file will be created there as needed with permission set to 0644, having the same group and ownership with Kubelet. |
|
||||
| `File` | A file must exist at the given path |
|
||||
| `Socket` | A UNIX socket must exist at the given path |
|
||||
| `CharDevice` | A character device must exist at the given path |
|
||||
| `BlockDevice` | A block device must exist at the given path |
|
||||
| `CharDevice` | _(Linux nodes only)_ A character device must exist at the given path |
|
||||
| `BlockDevice` | _(Linux nodes only)_ A block device must exist at the given path |
|
||||
-->
|
||||
| 取值 | 行为 |
|
||||
|:------|:---------|
|
||||
| | 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 |
|
||||
| `""` | 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 |
|
||||
| `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。 |
|
||||
| `Directory` | 在给定路径上必须存在的目录。|
|
||||
| `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。|
|
||||
| `File` | 在给定路径上必须存在的文件。|
|
||||
| `Socket` | 在给定路径上必须存在的 UNIX 套接字。|
|
||||
| `CharDevice` | 在给定路径上必须存在的字符设备。|
|
||||
| `BlockDevice` | 在给定路径上必须存在的块设备。|
|
||||
| `CharDevice` | **（仅 Linux 节点）** 在给定路径上必须存在的字符设备。|
|
||||
| `BlockDevice` | **（仅 Linux 节点）** 在给定路径上必须存在的块设备。|
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
The `FileOrCreate` mode does **not** create the parent directory of the file. If the parent directory
|
||||
of the mounted file does not exist, the pod fails to start. To ensure that this mode works,
|
||||
you can try to mount directories and files separately, as shown in the
|
||||
[`FileOrCreate` example](#hostpath-fileorcreate-example) for `hostPath`.
|
||||
-->
|
||||
`FileOrCreate` 模式**不会**创建文件的父目录。如果挂载文件的父目录不存在，Pod 将启动失败。
|
||||
为了确保这种模式正常工作，你可以尝试分别挂载目录和文件，如
|
||||
`hostPath` 的 [`FileOrCreate` 示例](#hostpath-fileorcreate-example)所示。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
Watch out when using this type of volume, because:
|
||||
|
||||
* HostPaths can expose privileged system credentials (such as for the Kubelet) or privileged APIs
|
||||
(such as container runtime socket), which can be used for container escape or to attack other
|
||||
parts of the cluster.
|
||||
* Pods with identical configuration (such as created from a PodTemplate) may
|
||||
behave differently on different nodes due to different files on the nodes
|
||||
* The files or directories created on the underlying hosts are only writable by root. You
|
||||
either need to run your process as root in a
|
||||
[privileged Container](/docs/tasks/configure-pod-container/security-context/) or modify the file
|
||||
permissions on the host to be able to write to a `hostPath` volume
|
||||
Some files or directories created on the underlying hosts might only be
|
||||
accessible by root. You then either need to run your process as root in a
|
||||
[privileged container](/docs/tasks/configure-pod-container/security-context/)
|
||||
or modify the file permissions on the host to be able to read from
|
||||
(or write to) a `hostPath` volume.
|
||||
-->
|
||||
当使用这种类型的卷时要小心，因为：
|
||||
|
||||
* HostPath 卷可能会暴露特权系统凭据（例如 Kubelet）或特权
|
||||
API（例如容器运行时套接字），可用于容器逃逸或攻击集群的其他部分。
|
||||
* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod
|
||||
会由于节点上文件的不同而在不同节点上有不同的行为。
|
||||
* 下层主机上创建的文件或目录只能由 root 用户写入。
|
||||
你需要在[特权容器](/zh-cn/docs/tasks/configure-pod-container/security-context/)中以
|
||||
root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。
|
||||
下层主机上创建的某些文件或目录只能由 root 用户访问。
|
||||
此时，你需要在[特权容器](/zh-cn/docs/tasks/configure-pod-container/security-context/)中以
|
||||
root 身份运行进程，或者修改主机上的文件权限，以便能够从 `hostPath` 卷读取数据（或将数据写入到 `hostPath` 卷）。
|
||||
|
||||
<!--
|
||||
#### hostPath configuration example
|
||||
|
|
@ -725,48 +814,115 @@ Watch out when using this type of volume, because:
|
|||
#### hostPath 配置示例
|
||||
|
||||
<!--
|
||||
Linux node
|
||||
# This manifest mounts /data/foo on the host as /foo inside the
|
||||
# single container that runs within the hostpath-example-linux Pod.
|
||||
#
|
||||
# The mount into the container is read-only.
|
||||
|
||||
# mount /data/foo, but only if that directory already exists
|
||||
|
||||
# directory location on host
|
||||
# this field is optional
|
||||
-->
|
||||
```yaml
|
||||
{{< tabs name="hostpath_examples" >}}
|
||||
{{< tab name="Linux 节点" codelang="yaml" >}}
|
||||
---
|
||||
# 此清单将主机上的 /data/foo 挂载为 hostpath-example-linux Pod 中运行的单个容器内的 /foo
|
||||
#
|
||||
# 容器中的挂载是只读的
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: test-pd
|
||||
name: hostpath-example-linux
|
||||
spec:
|
||||
os: { name: linux }
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
containers:
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
- name: example-container
|
||||
image: registry.k8s.io/test-webserver
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
name: test-volume
|
||||
- mountPath: /foo
|
||||
name: example-volume
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: test-volume
|
||||
- name: example-volume
|
||||
# 挂载 /data/foo，但仅当该目录已经存在时
|
||||
hostPath:
|
||||
# 宿主机上目录位置
|
||||
path: /data
|
||||
# 此字段为可选
|
||||
type: Directory
|
||||
```
|
||||
path: /data/foo # 主机上的目录位置
|
||||
type: Directory # 此字段可选
|
||||
{{< /tab >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
The `FileOrCreate` mode does not create the parent directory of the file. If the parent directory
|
||||
of the mounted file does not exist, the pod fails to start. To ensure that this mode works,
|
||||
you can try to mount directories and files separately, as shown in the
|
||||
[`FileOrCreate`configuration](#hostpath-fileorcreate-example).
|
||||
Windows node
|
||||
# This manifest mounts C:\Data\foo on the host as C:\foo, inside the
|
||||
# single container that runs within the hostpath-example-windows Pod.
|
||||
#
|
||||
# The mount into the container is read-only.
|
||||
|
||||
# mount C:\Data\foo from the host, but only if that directory already exists
|
||||
|
||||
# directory location on host
|
||||
# this field is optional
|
||||
-->
|
||||
`FileOrCreate` 模式不会负责创建文件的父目录。
|
||||
如果欲挂载的文件的父目录不存在，Pod 启动会失败。
|
||||
为了确保这种模式能够工作，可以尝试把文件和它对应的目录分开挂载，如
|
||||
[`FileOrCreate` 配置](#hostpath-fileorcreate-example)所示。
|
||||
{{< /caution >}}
|
||||
{{< tab name="Windows 节点" codelang="yaml" >}}
|
||||
---
|
||||
# 此清单将主机上的 C:\Data\foo 挂载为 hostpath-example-windows Pod 中运行的单个容器内的 C:\foo
|
||||
#
|
||||
# 容器中的挂载是只读的
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hostpath-example-windows
|
||||
spec:
|
||||
os: { name: windows }
|
||||
nodeSelector:
|
||||
kubernetes.io/os: windows
|
||||
containers:
|
||||
- name: example-container
|
||||
image: microsoft/windowsservercore:1709
|
||||
volumeMounts:
|
||||
- name: example-volume
|
||||
mountPath: "C:\\foo"
|
||||
readOnly: true
|
||||
volumes:
|
||||
# 从主机挂载 C:\Data\foo，但仅当该目录已经存在时
|
||||
- name: example-volume
|
||||
hostPath:
|
||||
path: "C:\\Data\\foo" # 主机上的目录位置
|
||||
type: Directory # 此字段可选
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
#### hostPath FileOrCreate configuration example {#hostpath-fileorcreate-example}
|
||||
-->
|
||||
#### hostPath FileOrCreate 配置示例 {#hostpath-fileorcreate-example}
|
||||
|
||||
<!--
|
||||
The following manifest defines a Pod that mounts `/var/local/aaa`
|
||||
inside the single container in the Pod. If the node does not
|
||||
already have a path `/var/local/aaa`, the kubelet creates
|
||||
it as a directory and then mounts it into the Pod.
|
||||
|
||||
If `/var/local/aaa` already exists but is not a directory,
|
||||
the Pod fails. Additionally, the kubelet attempts to make
|
||||
a file named `/var/local/aaa/1.txt` inside that directory
|
||||
(as seen from the host); if something already exists at
|
||||
that path and isn't a regular file, the Pod fails.
|
||||
|
||||
Here's the example manifest:
|
||||
-->
|
||||
以下清单定义了一个 Pod，将 `/var/local/aaa` 挂载到 Pod 中的单个容器内。
|
||||
如果节点上还没有路径 `/var/local/aaa`，kubelet 会创建这一目录，然后将其挂载到 Pod 中。
|
||||
|
||||
如果 `/var/local/aaa` 已经存在但不是一个目录，Pod 会失败。
|
||||
此外，kubelet 还会尝试在该目录内创建一个名为 `/var/local/aaa/1.txt` 的文件（从主机的视角来看）；
|
||||
如果在该路径上已经存在某个东西且不是常规文件，则 Pod 会失败。
|
||||
|
||||
以下是清单示例：
|
||||
|
||||
<!--
|
||||
# Ensure the file directory is created.
|
||||
-->
|
||||
|
|
@ -776,6 +932,9 @@ kind: Pod
|
|||
metadata:
|
||||
name: test-webserver
|
||||
spec:
|
||||
os: { name: linux }
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
containers:
|
||||
- name: test-webserver
|
||||
image: registry.k8s.io/test-webserver:latest
|
||||
|
|
@ -1358,13 +1517,13 @@ To turn off the `vsphereVolume` plugin from being loaded by the controller manag
|
|||
## Using subPath {#using-subpath}
|
||||
|
||||
Sometimes, it is useful to share one volume for multiple uses in a single pod.
|
||||
The `volumeMounts.subPath` property specifies a sub-path inside the referenced volume
|
||||
The `volumeMounts[*].subPath` property specifies a sub-path inside the referenced volume
|
||||
instead of its root.
|
||||
-->
|
||||
## 使用 subPath {#using-subpath}
|
||||
|
||||
有时，在单个 Pod 中共享卷以供多方使用是很有用的。
|
||||
`volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。
|
||||
`volumeMounts[*].subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。
|
||||
|
||||
<!--
|
||||
The following example shows how to configure a Pod with a LAMP stack (Linux Apache MySQL PHP)
|
||||
|
|
@ -1797,13 +1956,43 @@ plugins to corresponding CSI plugins (which are expected to be installed and con
|
|||
As a result, operators do not have to make any
|
||||
configuration changes to existing Storage Classes, PersistentVolumes or PersistentVolumeClaims
|
||||
(referring to in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.
|
||||
|
||||
The operations and features that are supported include:
|
||||
provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
|
||||
-->
|
||||
`CSIMigration` 特性针对现有树内插件的操作会被定向到相应的 CSI 插件（应已安装和配置）。
|
||||
因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC（指树内插件）进行任何配置更改。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Existing PVs created by a in-tree volume plugin can still be used in the future without any configuration
|
||||
changes, even after the migration to CSI is completed for that volume type, and even after you upgrade to a
|
||||
version of Kubernetes that doesn't have compiled-in support for that kind of storage.
|
||||
|
||||
As part of that migration, you - or another cluster administrator - **must** have installed and configured
|
||||
the appropriate CSI driver for that storage. The core of Kubernetes does not install that software for you.
|
||||
-->
|
||||
即使你针对这种卷完成了 CSI 迁移且你升级到不再内置对这种存储类别的支持的 Kubernetes 版本，
|
||||
现有的由树内卷插件所创建的 PV 在未来无需进行任何配置更改就可以使用，
|
||||
|
||||
作为迁移的一部分，你或其他集群管理员**必须**安装和配置适用于该存储的 CSI 驱动。
|
||||
Kubernetes 不会为你安装该软件。
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
After that migration, you can also define new PVCs and PVs that refer to the legacy, built-in
|
||||
storage integrations.
|
||||
Provided you have the appropriate CSI driver installed and configured, the PV creation continues
|
||||
to work, even for brand new volumes. The actual storage management now happens through
|
||||
the CSI driver.
|
||||
-->
|
||||
在完成迁移之后，你也可以定义新的 PVC 和 PV，引用原来的、内置的集成存储。
|
||||
只要你安装并配置了适当的 CSI 驱动，即使是全新的卷，PV 的创建仍然可以继续工作。
|
||||
实际的存储管理现在通过 CSI 驱动来进行。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The operations and features that are supported include:
|
||||
provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
|
||||
-->
|
||||
所支持的操作和特性包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、
|
||||
挂载（Mount）/卸载（Unmount）和调整卷大小。
|
||||
|
||||
|
|
@ -1875,13 +2064,13 @@ Mount propagation allows for sharing volumes mounted by a container to
|
|||
other containers in the same pod, or even to other pods on the same node.
|
||||
|
||||
Mount propagation of a volume is controlled by the `mountPropagation` field
|
||||
in `Container.volumeMounts`. Its values are:
|
||||
in `containers[*].volumeMounts`. Its values are:
|
||||
-->
|
||||
## 挂载卷的传播 {#mount-propagation}
|
||||
|
||||
挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。
|
||||
|
||||
卷的挂载传播特性由 `Container.volumeMounts` 中的 `mountPropagation` 字段控制。
|
||||
卷的挂载传播特性由 `containers[*].volumeMounts` 中的 `mountPropagation` 字段控制。
|
||||
它的值包括：
|
||||
|
||||
<!--
|
||||
|
|
@ -1963,6 +2152,127 @@ in `Container.volumeMounts`. Its values are:
|
|||
此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
## Read-only mounts
|
||||
|
||||
A mount can be made read-only by setting the `.spec.containers[].volumeMounts[].readOnly`
|
||||
field to `true`.
|
||||
This does not make the volume itself read-only, but that specific container will
|
||||
not be able to write to it.
|
||||
Other containers in the Pod may mount the same volume as read-write.
|
||||
-->
|
||||
## 只读挂载 {#read-only-mounts}
|
||||
|
||||
通过将 `.spec.containers[].volumeMounts[].readOnly` 字段设置为 `true` 可以使挂载只读。
|
||||
这不会使卷本身只读，但该容器将无法写入此卷。
|
||||
Pod 中的其他容器可以以读写方式挂载同一个卷。
|
||||
|
||||
<!--
|
||||
On Linux, read-only mounts are not recursively read-only by default.
|
||||
For example, consider a Pod which mounts the hosts `/mnt` as a `hostPath` volume. If
|
||||
there is another filesystem mounted read-write on `/mnt/<SUBMOUNT>` (such as tmpfs,
|
||||
NFS, or USB storage), the volume mounted into the container(s) will also have a writeable
|
||||
`/mnt/<SUBMOUNT>`, even if the mount itself was specified as read-only.
|
||||
-->
|
||||
在 Linux 上，只读挂载默认不会以递归方式只读。
|
||||
假如有一个 Pod 将主机的 `/mnt` 挂载为 `hostPath` 卷。
|
||||
如果在 `/mnt/<SUBMOUNT>` 上有另一个以读写方式挂载的文件系统（如 tmpfs、NFS 或 USB 存储），
|
||||
即使挂载本身被指定为只读，挂载到容器中的卷 `/mnt/<SUBMOUNT>` 也是可写的。
|
||||
|
||||
<!--
|
||||
### Recursive read-only mounts
|
||||
-->
|
||||
### 递归只读挂载 {#recursive-read-only-mounts}
|
||||
|
||||
{{< feature-state feature_gate_name="RecursiveReadOnlyMounts" >}}
|
||||
|
||||
<!--
|
||||
Recursive read-only mounts can be enabled by setting the
|
||||
`RecursiveReadOnlyMounts` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
for kubelet and kube-apiserver, and setting the `.spec.containers[].volumeMounts[].recursiveReadOnly`
|
||||
field for a pod.
|
||||
-->
|
||||
通过为 kubelet 和 kube-apiserver 设置 `RecursiveReadOnlyMounts`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
|
||||
并为 Pod 设置 `.spec.containers[].volumeMounts[].recursiveReadOnly` 字段，
|
||||
递归只读挂载可以被启用。
|
||||
|
||||
<!--
|
||||
The allowed values are:
|
||||
|
||||
* `Disabled` (default): no effect.
|
||||
-->
|
||||
允许的值为：
|
||||
|
||||
* `Disabled`（默认）：无效果。
|
||||
|
||||
<!--
|
||||
* `Enabled`: makes the mount recursively read-only.
|
||||
Needs all the following requirements to be satisfied:
|
||||
* `readOnly` is set to `true`
|
||||
* `mountPropagation` is unset, or, set to `None`
|
||||
* The host is running with Linux kernel v5.12 or later
|
||||
* The [CRI-level](/docs/concepts/architecture/cri) container runtime supports recursive read-only mounts
|
||||
* The OCI-level container runtime supports recursive read-only mounts.
|
||||
It will fail if any of these is not true.
|
||||
-->
|
||||
* `Enabled`：使挂载递归只读。需要满足以下所有要求：
|
||||
|
||||
* `readOnly` 设置为 `true`
|
||||
* `mountPropagation` 不设置，或设置为 `None`
|
||||
* 主机运行 Linux 内核 v5.12 或更高版本
|
||||
* [CRI 级别](/zh-cn/docs/concepts/architecture/cri)的容器运行时支持递归只读挂载
|
||||
* OCI 级别的容器运行时支持递归只读挂载
|
||||
|
||||
如果其中任何一个不满足，递归只读挂载将会失败。
|
||||
|
||||
<!--
|
||||
* `IfPossible`: attempts to apply `Enabled`, and falls back to `Disabled`
|
||||
if the feature is not supported by the kernel or the runtime class.
|
||||
|
||||
Example:
|
||||
-->
|
||||
* `IfPossible`：尝试应用 `Enabled`，如果内核或运行时类不支持该特性，则回退为 `Disabled`。
|
||||
|
||||
示例：
|
||||
|
||||
{{% code_sample file="storage/rro.yaml" %}}
|
||||
|
||||
<!--
|
||||
When this property is recognized by kubelet and kube-apiserver,
|
||||
the `.status.containerStatuses[].volumeMounts[].recursiveReadOnly` field is set to either
|
||||
`Enabled` or `Disabled`.
|
||||
|
||||
#### Implementations {#implementations-rro}
|
||||
-->
|
||||
当此属性被 kubelet 和 kube-apiserver 识别到时，
|
||||
`.status.containerStatuses[].volumeMounts[].recursiveReadOnly` 字段将被设置为 `Enabled` 或 `Disabled`。
|
||||
|
||||
#### 实现 {#implementations-rro}
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
The following container runtimes are known to support recursive read-only mounts.
|
||||
|
||||
CRI-level:
|
||||
- [containerd](https://containerd.io/), since v2.0
|
||||
|
||||
OCI-level:
|
||||
- [runc](https://runc.io/), since v1.1
|
||||
- [crun](https://github.com/containers/crun), since v1.8.6
|
||||
-->
|
||||
以下容器运行时已知支持递归只读挂载。
|
||||
|
||||
CRI 级别：
|
||||
|
||||
- [containerd](https://containerd.io/)，自 v2.0 起
|
||||
|
||||
OCI 级别：
|
||||
|
||||
- [runc](https://runc.io/)，自 v1.1 起
|
||||
- [crun](https://github.com/containers/crun)，自 v1.8.6 起
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -29,14 +29,13 @@ tags:
|
|||
|
||||
<!--
|
||||
A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component
|
||||
that embeds cloud-specific control logic. The [cloud controller manager](/docs/concepts/architecture/cloud-controller/) lets you link your
|
||||
that embeds cloud-specific control logic. The cloud controller manager lets you link your
|
||||
cluster into your cloud provider's API, and separates out the components that interact
|
||||
with that cloud platform from components that only interact with your cluster.
|
||||
-->
|
||||
一个 Kubernetes {{<glossary_tooltip text="控制平面" term_id="control-plane" >}}组件，
|
||||
嵌入了特定于云平台的控制逻辑。
|
||||
[云控制器管理器（Cloud Controller Manager）](/zh-cn/docs/concepts/architecture/cloud-controller/)
|
||||
允许将你的集群连接到云提供商的 API 之上，
|
||||
云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上，
|
||||
并将与该云平台交互的组件同与你的集群交互的组件分离开来。
|
||||
|
||||
<!--more-->
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Kubernetes reserves all labels and annotations in the `kubernetes.io` and `k8s.i
|
|||
|
||||
This document serves both as a reference to the values and as a coordination point for assigning values.
|
||||
-->
|
||||
Kubernetes 将所有标签和注解保留在 `kubernetes.io` 和 `k8s.io `名字空间中。
|
||||
Kubernetes 将所有标签和注解保留在 `kubernetes.io` 和 `k8s.io` 名字空间中。
|
||||
|
||||
本文档既可作为值的参考，也可作为分配值的协调点。
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ Starting from v1.9, this label is deprecated.
|
|||
|
||||
Type: Label
|
||||
|
||||
Example: `app.kubernetes.io/instance: "mysql-abcxzy"`
|
||||
Example: `app.kubernetes.io/instance: "mysql-abcxyz"`
|
||||
|
||||
Used on: All Objects (typically used on
|
||||
[workload resources](/docs/reference/kubernetes-api/workload-resources/)).
|
||||
|
|
@ -138,7 +138,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com
|
|||
|
||||
类别：标签
|
||||
|
||||
示例：`app.kubernetes.io/instance: "mysql-abcxzy"`
|
||||
示例：`app.kubernetes.io/instance: "mysql-abcxyz"`
|
||||
|
||||
用于：所有对象（通常用于[工作负载资源](/zh-cn/docs/reference/kubernetes-api/workload-resources/)）。
|
||||
|
||||
|
|
@ -260,26 +260,13 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com
|
|||
[推荐标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!--
|
||||
### applyset.kubernetes.io/additional-namespaces (alpha) {#applyset-kubernetes-io-additional-namespaces}
|
||||
### applyset.kubernetes.io/contains-group-kinds (alpha) {#applyset-kubernetes-io-contains-group-kinds}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example: `applyset.kubernetes.io/additional-namespaces: "namespace1,namespace2"`
|
||||
Example: `applyset.kubernetes.io/contains-group-kinds: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
|
||||
Used on: Objects being used as ApplySet parents.
|
||||
|
||||
Use of this annotation is Alpha.
|
||||
For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets,
|
||||
ConfigMaps, or custom resources if the
|
||||
{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}}
|
||||
defining them has the `applyset.kubernetes.io/is-parent-type` label.
|
||||
|
||||
Part of the specification used to implement
|
||||
[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune).
|
||||
This annotation is applied to the parent object used to track an ApplySet to extend the scope of
|
||||
the ApplySet beyond the parent object's own namespace (if any).
|
||||
The value is a comma-separated list of the names of namespaces other than the parent's namespace
|
||||
in which objects are found.
|
||||
-->
|
||||
### applyset.kubernetes.io/additional-namespaces (alpha) {#applyset-kubernetes-io-additional-namespaces}
|
||||
|
||||
|
|
@ -289,16 +276,32 @@ in which objects are found.
|
|||
|
||||
用于：作为 ApplySet 父对象使用的对象。
|
||||
|
||||
<!--
|
||||
Use of this annotation is Alpha.
|
||||
For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, ConfigMaps,
|
||||
or custom resources if the CustomResourceDefinition
|
||||
defining them has the `applyset.kubernetes.io/is-parent-type` label.
|
||||
|
||||
Part of the specification used to implement
|
||||
[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune).
|
||||
This annotation is applied to the parent object used to track an ApplySet to optimize listing of
|
||||
ApplySet member objects. It is optional in the ApplySet specification, as tools can perform discovery
|
||||
or use a different optimization. However, as of Kubernetes version {{< skew currentVersion >}},
|
||||
it is required by kubectl. When present, the value of this annotation must be a comma separated list
|
||||
of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`.
|
||||
-->
|
||||
此注解处于 alpha 阶段。
|
||||
对于 Kubernetes {{< skew currentVersion >}} 版本，如果定义它们的
|
||||
{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}}
|
||||
打了 `applyset.kubernetes.io/is-parent-type` 标签，
|
||||
那么你可以在 Secret、ConfigMaps 或自定义资源上使用此注解。
|
||||
那么你可以在 Secret、ConfigMap 或自定义资源上使用此注解。
|
||||
|
||||
规范的部分功能用来实现
|
||||
[在 kubectl 中基于 ApplySet 的删除](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune)。
|
||||
此注解应用于父对象，这些父对象用于跟踪 ApplySet 以将 ApplySet 的作用域扩展到父对象自己的命名空间(如果有的话)之外。
|
||||
注解的值是以逗号分隔的命名空间的名字列表，不包含在其中找到对象的父命名空间。
|
||||
此注解应用于父对象，这些父对象用于跟踪 ApplySet 以优化 ApplySet 成员对象列表。
|
||||
它在 AppySet 规范中是可选的，因为工具可以执行发现或使用不同的优化。
|
||||
然而，对于 Kubernetes {{< skew currentVersion >}} 版本，它是 kubectl 必需的。
|
||||
当存在时，注解的值必须是一个以逗号分隔的 group-kinds 列表，采用完全限定的名称格式，例如 `<resource>.<group>`。
|
||||
|
||||
<!--
|
||||
### applyset.kubernetes.io/contains-group-resources (alpha) {#applyset-kubernetes-io-contains-group-resources}
|
||||
|
|
@ -338,11 +341,61 @@ of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>
|
|||
|
||||
规范的部分功能用来实现
|
||||
[在 kubectl 中基于 ApplySet 的删除](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune)。
|
||||
此注解应用于父对象， 这些父对象用于跟踪 ApplySet 以优化 ApplySet 成员对象列表。
|
||||
此注解应用于父对象，这些父对象用于跟踪 ApplySet 以优化 ApplySet 成员对象列表。
|
||||
它在 AppySet 规范中是可选的，因为工具可以执行发现或使用不同的优化。
|
||||
然而，对于 Kubernetes {{< skew currentVersion >}} 版本，它是 kubectl 必需的。
|
||||
当存在时，注解的值必须是一个以逗号分隔的 group-kinds 列表，采用完全限定的名称格式，例如 `<resource>.<group>`。
|
||||
|
||||
<!--
|
||||
### applyset.kubernetes.io/contains-group-resources (deprecated) {#applyset-kubernetes-io-contains-group-resources}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example: `applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
|
||||
Used on: Objects being used as ApplySet parents.
|
||||
-->
|
||||
### applyset.kubernetes.io/contains-group-resources (已弃用) {#applyset-kubernetes-io-contains-group-resources}
|
||||
|
||||
类别：注解
|
||||
|
||||
例子：`applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"`
|
||||
|
||||
用于：作为 ApplySet 父对象的对象。
|
||||
|
||||
<!--
|
||||
For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, ConfigMaps,
|
||||
or custom resources if the CustomResourceDefinition
|
||||
defining them has the `applyset.kubernetes.io/is-parent-type` label.
|
||||
|
||||
Part of the specification used to implement
|
||||
[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune).
|
||||
This annotation is applied to the parent object used to track an ApplySet to optimize listing of
|
||||
ApplySet member objects. It is optional in the ApplySet specification, as tools can perform discovery
|
||||
or use a different optimization. However, in Kubernetes version {{< skew currentVersion >}},
|
||||
it is required by kubectl. When present, the value of this annotation must be a comma separated list
|
||||
of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`.
|
||||
-->
|
||||
对于 Kubernetes {{< skew currentVersion >}} 版本，如果定义它们的
|
||||
CustomResourceDefinition 打了 `applyset.kubernetes.io/is-parent-type` 标签，
|
||||
那么你可以在 Secret、ConfigMap 或自定义资源上使用此注解。
|
||||
|
||||
规范的部分功能用来实现
|
||||
[在 kubectl 中基于 ApplySet 的删除](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune)。
|
||||
此注解应用于父对象，这些父对象用于跟踪 ApplySet 以优化 ApplySet 成员对象列表。
|
||||
它在 AppySet 规范中是可选的，因为工具可以执行发现或使用不同的优化。
|
||||
然而，对于 Kubernetes {{< skew currentVersion >}} 版本，它是 kubectl 必需的。
|
||||
当存在时，注解的值必须是一个以逗号分隔的 group-kinds 列表，采用完全限定的名称格式，例如 `<resource>.<group>`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
This annotation is currently deprecated and replaced by [`applyset.kubernetes.io/contains-group-kinds`](#applyset-kubernetes-io-contains-group-kinds),
|
||||
support for this will be removed in applyset beta or GA.
|
||||
-->
|
||||
此注解目前已弃用，替换为 [`applyset.kubernetes.io/contains-group-kinds`](#applyset-kubernetes-io-contains-group-kinds)，
|
||||
对此注解的支持将在 ApplySet 进阶至 Beta 或 GA 后移除。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### applyset.kubernetes.io/id (alpha) {#applyset-kubernetes-io-id}
|
||||
|
||||
|
|
@ -585,7 +638,10 @@ For example, Kustomize removes objects with this annotation from its final build
|
|||
该注解是 Kubernetes 资源模型 (KRM) 函数规范的一部分，被 Kustomize 和其他类似的第三方工具使用。
|
||||
例如，Kustomize 会从其最终构建输出中删除带有此注解的对象。
|
||||
|
||||
### container.apparmor.security.beta.kubernetes.io/* (beta) {#container-apparmor-security-beta-kubernetes-io}
|
||||
<!--
|
||||
### container.apparmor.security.beta.kubernetes.io/* (deprecated) {#container-apparmor-security-beta-kubernetes-io}
|
||||
-->
|
||||
### container.apparmor.security.beta.kubernetes.io/*（已弃用） {#container-apparmor-security-beta-kubernetes-io}
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
|
@ -595,7 +651,7 @@ Example: `container.apparmor.security.beta.kubernetes.io/my-container: my-custom
|
|||
Used on: Pods
|
||||
|
||||
This annotation allows you to specify the AppArmor security profile for a container within a
|
||||
Kubernetes pod.
|
||||
Kubernetes pod. As of Kubernetes v1.30, this should be set with the `appArmorProfile` field instead.
|
||||
To learn more, see the [AppArmor](/docs/tutorials/security/apparmor/) tutorial.
|
||||
The tutorial illustrates using AppArmor to restrict a container's abilities and access.
|
||||
|
||||
|
|
@ -609,6 +665,7 @@ adhere to. This helps enforce security policies and isolation for your container
|
|||
用于：Pod
|
||||
|
||||
此注解允许你为 Kubernetes Pod 中的容器指定 AppArmor 安全配置文件。
|
||||
从 Kubernetes v1.30 开始，此注解应该通过 `appArmorProfile` 字段进行设置。
|
||||
更多细节参阅 [AppArmor](/zh-cn/docs/tutorials/security/apparmor/) 教程。
|
||||
该教程演示了如何使用 AppArmor 限制容器的权能和访问权限。
|
||||
|
||||
|
|
@ -843,6 +900,108 @@ Kubernetes 默认不提供任何资源限制，这意味着除非你明确定义
|
|||
注解 `kubernetes.io/limit-ranger` 记录了为 Pod 指定的资源默认值，以及成功应用这些默认值。
|
||||
有关更多详细信息，请阅读 [LimitRanges](/zh-cn/docs/concepts/policy/limit-range)。
|
||||
|
||||
### kubernetes.io/config.hash
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `kubernetes.io/config.hash: "df7cc47f8477b6b1226d7d23a904867b"`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
When the kubelet creates a static Pod based on a given manifest, it attaches this annotation
|
||||
to the static Pod. The value of the annotation is the UID of the Pod.
|
||||
Note that the kubelet also sets the `.spec.nodeName` to the current node name as if the Pod
|
||||
was scheduled to the node.
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`kubernetes.io/config.hash: "df7cc47f8477b6b1226d7d23a904867b"`
|
||||
|
||||
用于：Pod
|
||||
|
||||
当 kubelet 基于给定的清单创建静态 Pod 时，kubelet 会将此注解挂接到静态 Pod 上。
|
||||
注解的取值是 Pod 的 UID。请注意，kubelet 还会将 `.spec.nodeName` 设置为当前节点名称，
|
||||
就像 Pod 被调度到此节点一样。
|
||||
|
||||
### kubernetes.io/config.mirror
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `kubernetes.io/config.mirror: "df7cc47f8477b6b1226d7d23a904867b"`
|
||||
|
||||
Used on: Pod
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`kubernetes.io/config.mirror: "df7cc47f8477b6b1226d7d23a904867b"`
|
||||
|
||||
用于：Pod
|
||||
|
||||
<!--
|
||||
For a static Pod created by the kubelet on a node, a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
|
||||
is created on the API server. The kubelet adds an annotation to indicate that this Pod is
|
||||
actually a mirror Pod. The annotation value is copied from the [`kubernetes.io/config.hash`](#kubernetes-io-config-hash)
|
||||
annotation, which is the UID of the Pod.
|
||||
|
||||
When updating a Pod with this annotation set, the annotation cannot be changed or removed.
|
||||
If a Pod doesn't have this annotation, it cannot be added during a Pod update.
|
||||
-->
|
||||
对于 kubelet 在节点上创建的静态 Pod，
|
||||
系统会在 API 服务器上创建{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
|
||||
kubelet 添加一个注解以指示此 Pod 实际上是镜像 Pod。
|
||||
注解的值是从 [`kubernetes.io/config.hash`](#kubernetes-io-config-hash) 注解复制过来的，即 Pod 的 UID。
|
||||
|
||||
在更新设置了此注解的 Pod 时，注解不能被更改或移除。
|
||||
如果 Pod 没有此注解，此注解在 Pod 更新期间不能被添加。
|
||||
|
||||
### kubernetes.io/config.source
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `kubernetes.io/config.source: "file"`
|
||||
|
||||
Used on: Pod
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`kubernetes.io/config.source: "file"`
|
||||
|
||||
用于：Pod
|
||||
|
||||
<!--
|
||||
This annotation is added by the kubelet to indicate where the Pod comes from.
|
||||
For static Pods, the annotation value could be one of `file` or `http` depending
|
||||
on where the Pod manifest is located. For a Pod created on the API server and then
|
||||
scheduled to the current node, the annotation value is `api`.
|
||||
-->
|
||||
此注解由 kubelet 添加，以指示 Pod 的来源。
|
||||
对于静态 Pod，注解的值可以是 `file` 或 `http` 之一，具体取决于 Pod 清单所在的位置。
|
||||
对于在 API 服务器上创建并调度到当前节点的 Pod，注解的值是 `api`。
|
||||
|
||||
### kubernetes.io/config.seen
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `kubernetes.io/config.seen: "2023-10-27T04:04:56.011314488Z"`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
When the kubelet sees a Pod for the first time, it may add this annotation to
|
||||
the Pod with a value of current timestamp in the RFC3339 format.
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`kubernetes.io/config.seen: "2023-10-27T04:04:56.011314488Z"`
|
||||
|
||||
用于：Pod
|
||||
|
||||
当 kubelet 第一次看到 Pod 时，kubelet 可以将此注解添加到 Pod 上，
|
||||
注解的值是格式为 RFC3339 的当前时间戳。
|
||||
|
||||
<!--
|
||||
### addonmanager.kubernetes.io/mode
|
||||
|
||||
|
|
@ -1062,8 +1221,8 @@ Example: `kubernetes.io/enforce-mountable-secrets: "true"`
|
|||
Used on: ServiceAccount
|
||||
|
||||
The value for this annotation must be **true** to take effect.
|
||||
This annotation indicates that Pods running as this ServiceAccount may only reference
|
||||
Secret API objects specified in the ServiceAccount's `secrets` field.
|
||||
When you set this annotation to "true", Kubernetes enforces the following rules for
|
||||
Pods running as this ServiceAccount:
|
||||
-->
|
||||
### kubernetes.io/enforce-mountable-secrets {#enforce-mountable-secrets}
|
||||
|
||||
|
|
@ -1073,8 +1232,37 @@ Secret API objects specified in the ServiceAccount's `secrets` field.
|
|||
|
||||
用于：ServiceAccount
|
||||
|
||||
此注解的值必须为 **true** 才能生效。此注解表示作为此服务账号运行的 Pod
|
||||
只能引用在服务账号的 `secrets` 字段中指定的 Secret API 对象。
|
||||
此注解的值必须为 **true** 才能生效。
|
||||
当你将此注解设置为 "true" 时，Kubernetes 会对以此 ServiceAccount 运行的 Pod 强制执行以下规则：
|
||||
|
||||
<!--
|
||||
1. Secrets mounted as volumes must be listed in the ServiceAccount's `secrets` field.
|
||||
1. Secrets referenced in `envFrom` for containers (including sidecar containers and init containers)
|
||||
must also be listed in the ServiceAccount's secrets field.
|
||||
If any container in a Pod references a Secret not listed in the ServiceAccount's `secrets` field
|
||||
(and even if the reference is marked as `optional`), then the Pod will fail to start,
|
||||
and an error indicating the non-compliant secret reference will be generated.
|
||||
1. Secrets referenced in a Pod's `imagePullSecrets` must be present in the
|
||||
ServiceAccount's `imagePullSecrets` field, the Pod will fail to start,
|
||||
and an error indicating the non-compliant image pull secret reference will be generated.
|
||||
-->
|
||||
1. 作为卷挂载的 Secret 必须列在 ServiceAccount 的 `secrets` 字段中。
|
||||
2. 针对容器（包括边车容器和 Init 容器）在 `envFrom` 中引用的 Secret 也必须列在 ServiceAccount 的 `secrets` 字段中。
|
||||
如果 Pod 中的任一容器引用了未在 ServiceAccount 的 `secrets` 字段中列出的 Secret（即使该引用被标记为 `optional`），
|
||||
则 Pod 将启动失败，并报错表示不合规的 Secret 引用。
|
||||
3. 在 Pod 的 `imagePullSecrets` 中引用的 Secret 必须出现在 ServiceAccount 的 `imagePullSecrets` 字段中，
|
||||
否则 Pod 将启动失败，并报错表示不合规的镜像拉取 Secret 引用。
|
||||
|
||||
<!--
|
||||
When you create or update a Pod, these rules are checked. If a Pod doesn't follow them, it won't start and you'll see an error message.
|
||||
If a Pod is already running and you change the `kubernetes.io/enforce-mountable-secrets` annotation
|
||||
to true, or you edit the associated ServiceAccount to remove the reference to a Secret
|
||||
that the Pod is already using, the Pod continues to run.
|
||||
-->
|
||||
当你创建或更新 Pod 时，系统会检查这些规则。
|
||||
如果 Pod 未遵循这些规则，Pod 将启动失败，并且你将看到一条错误消息。
|
||||
如果 Pod 已经在运行，并且你将 `kubernetes.io/enforce-mountable-secrets` 注解更改为 true，
|
||||
或者你编辑关联的 ServiceAccount 以移除 Pod 已经在使用的对 Secret 的引用，那么 Pod 将继续运行。
|
||||
|
||||
<!--
|
||||
### node.kubernetes.io/exclude-from-external-load-balancers
|
||||
|
|
@ -1085,9 +1273,7 @@ Example: `node.kubernetes.io/exclude-from-external-load-balancers`
|
|||
|
||||
Used on: Node
|
||||
|
||||
Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on
|
||||
the clusters it creates. With this feature gate enabled on a cluster,
|
||||
you can add labels to particular worker nodes to exclude them from the list of backend servers.
|
||||
You can add labels to particular worker nodes to exclude them from the list of backend servers used by external load balancers.
|
||||
The following command can be used to exclude a worker node from the list of backend servers in a
|
||||
backend set:
|
||||
-->
|
||||
|
|
@ -1099,8 +1285,7 @@ backend set:
|
|||
|
||||
用于：Node
|
||||
|
||||
Kubernetes 自动在其创建的集群上启用 `ServiceNodeExclusion` 特性门控。
|
||||
在一个集群上启用此特性门控后，你可以添加标签到特定的 Worker 节点，将这些节点从后端服务器列表排除在外。
|
||||
你可以向特定的 Worker 节点添加标签，以将这些节点从外部负载均衡器使用的后端服务器列表中去除。
|
||||
以下命令可用于从后端集的后端服务器列表中排除一个 Worker 节点：
|
||||
|
||||
```shell
|
||||
|
|
@ -1603,7 +1788,7 @@ Zone 级别的 Pod 分布是通过 **SelectorSpreadPriority** 实现的。
|
|||
_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are
|
||||
heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod
|
||||
resource requirements), this placement might prevent equal spreading of your Pods across zones.
|
||||
If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability
|
||||
If desired, you can use homogeneous zones (same number and types of nodes) to reduce the probability
|
||||
of unequal spreading.
|
||||
-->
|
||||
**SelectorSpreadPriority** 是一个尽力而为的放置机制。如果集群中的 Zone 是异构的
|
||||
|
|
@ -1808,9 +1993,10 @@ Type: Label
|
|||
|
||||
Example: `service.kubernetes.io/headless: ""`
|
||||
|
||||
Used on: Service
|
||||
Used on: Endpoints
|
||||
|
||||
The control plane adds this label to an Endpoints object when the owning Service is headless.
|
||||
To learn more, read [Headless Services](/docs/concepts/services-networking/service/#headless-services).
|
||||
-->
|
||||
### service.kubernetes.io/headless {#servicekubernetesioheadless}
|
||||
|
||||
|
|
@ -1818,9 +2004,10 @@ The control plane adds this label to an Endpoints object when the owning Service
|
|||
|
||||
例子：`service.kubernetes.io/headless: ""`
|
||||
|
||||
用于：Service
|
||||
用于：Endpoints
|
||||
|
||||
当拥有的 Service 是无头类型时，控制平面将此标签添加到 Endpoints 对象。
|
||||
更多细节参阅[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)。
|
||||
|
||||
<!--
|
||||
### service.kubernetes.io/topology-aware-hints (deprecated) {#servicekubernetesiotopology-aware-hints}
|
||||
|
|
@ -2000,12 +2187,39 @@ then the label isn't set.
|
|||
|
||||
如果上一次使用老的令牌的时间在集群获得此特性（添加于 Kubernetes v1.26）之前，则不会设置此标签。
|
||||
|
||||
### kubernetes.io/legacy-token-invalid-since
|
||||
|
||||
<!--
|
||||
Type: Label
|
||||
|
||||
Example: `kubernetes.io/legacy-token-invalid-since: 2023-10-27`
|
||||
|
||||
Used on: Secret
|
||||
-->
|
||||
类别：标签
|
||||
|
||||
例子：`kubernetes.io/legacy-token-invalid-since: 2023-10-27`
|
||||
|
||||
用于：Secret
|
||||
|
||||
<!--
|
||||
The control plane automatically adds this label to auto-generated Secrets that
|
||||
have the type `kubernetes.io/service-account-token`. This label marks the
|
||||
Secret-based token as invalid for authentication. The value of this label
|
||||
records the date (ISO 8601 format, UTC time zone) when the control plane detects
|
||||
that the auto-generated Secret has not been used for a specified duration
|
||||
(defaults to one year).
|
||||
-->
|
||||
控制平面会自动将此标签添加到类别为 `kubernetes.io/service-account-token` 的自动生成的 Secret 中。
|
||||
此标签将基于 Secret 的令牌标记为无效的认证令牌。此标签的值记录了控制平面检测到自动生成的
|
||||
Secret 在指定时间段内（默认是一年）未被使用的日期（ISO 8601 格式，UTC 时区）。
|
||||
|
||||
<!--
|
||||
### endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
|
||||
|
||||
Type: Label
|
||||
|
||||
Example: `endpointslice.kubernetes.io/managed-by: "controller"`
|
||||
Example: `endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io`
|
||||
|
||||
Used on: EndpointSlices
|
||||
|
||||
|
|
@ -2017,7 +2231,7 @@ within the same cluster.
|
|||
|
||||
类别：标签
|
||||
|
||||
例子：`endpointslice.kubernetes.io/managed-by: "controller"`
|
||||
例子：`endpointslice.kubernetes.io/managed-by: "endpointslice-controller.k8s.io"`
|
||||
|
||||
用于：EndpointSlice
|
||||
|
||||
|
|
@ -2328,6 +2542,43 @@ to track changes. That mechanism has been superseded by
|
|||
kubectl 命令行工具使用此注解作为一种旧的机制来跟踪变更。
|
||||
该机制已被[服务器端应用](/zh-cn/docs/reference/using-api/server-side-apply/)取代。
|
||||
|
||||
### kubectl.kubernetes.io/restartedAt {#kubectl-k8s-io-restart-at}
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `kubectl.kubernetes.io/restartedAt: "2024-06-21T17:27:41Z"`
|
||||
|
||||
Used on: Deployment, ReplicaSet, StatefulSet, DaemonSet, Pod
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`kubectl.kubernetes.io/restartedAt: "2024-06-21T17:27:41Z"`
|
||||
|
||||
用于：Deployment、ReplicaSet、StatefulSet、DaemonSet、Pod
|
||||
|
||||
<!--
|
||||
This annotation contains the latest restart time of a resource (Deployment, ReplicaSet, StatefulSet or DaemonSet),
|
||||
where kubectl triggered a rollout in order to force creation of new Pods.
|
||||
The command `kubectl rollout restart <RESOURCE>` triggers a restart by patching the template
|
||||
metadata of all the pods of resource with this annotation. In above example the latest restart time is shown as 21st June 2024 at 17:27:41 UTC.
|
||||
-->
|
||||
此注解包含资源（Deployment、ReplicaSet、StatefulSet 或 DaemonSet）的最新重启时间，
|
||||
kubectl 通过触发一次 rollout 来强制创建新的 Pod。
|
||||
`kubectl rollout restart <RESOURCE>` 命令触发资源重启时给资源的所有 Pod 的模板元数据打上此注解补丁。
|
||||
在上述例子中，最新的重启时间显示为 2024 年 6 月 21 日 17:27:41 UTC。
|
||||
|
||||
<!--
|
||||
You should not assume that this annotation represents the date / time of the most recent update;
|
||||
a separate change could have been made since the last manually triggered rollout.
|
||||
|
||||
If you manually set this annotation on a Pod, nothing happens. The restarting side effect comes from
|
||||
how workload management and Pod templating works.
|
||||
-->
|
||||
你不应假设此注解代表最近一次更新的日期/时间；在上次手动触发的 rollout 之后，可能还进行了其他独立更改。
|
||||
|
||||
如果你手动在 Pod 上设置此注解，什么都不会发生。这个重启的副作用是工作负载管理和 Pod 模板化的工作方式所造成的。
|
||||
|
||||
<!--
|
||||
### endpoints.kubernetes.io/over-capacity
|
||||
|
||||
|
|
@ -2360,6 +2611,29 @@ If the number of backend endpoints falls below 1000, the control plane removes t
|
|||
|
||||
如果后端端点的数量低于 1000，则控制平面将移除此注解。
|
||||
|
||||
### endpoints.kubernetes.io/last-change-trigger-time
|
||||
|
||||
<!--
|
||||
Type: Annotation
|
||||
|
||||
Example: `endpoints.kubernetes.io/last-change-trigger-time: "2023-07-20T04:45:21Z"`
|
||||
|
||||
Used on: Endpoints
|
||||
|
||||
This annotation set to an [Endpoints](/docs/concepts/services-networking/service/#endpoints) object that
|
||||
represents the timestamp (The timestamp is stored in RFC 3339 date-time string format. For example, '2018-10-22T19:32:52.1Z'). This is timestamp
|
||||
of the last change in some Pod or Service object, that triggered the change to the Endpoints object.
|
||||
-->
|
||||
类别：注解
|
||||
|
||||
例子：`endpoints.kubernetes.io/last-change-trigger-time: "2023-07-20T04:45:21Z"`
|
||||
|
||||
用于：Endpoints
|
||||
|
||||
此注解设置在 [Endpoints](/zh-cn/docs/concepts/services-networking/service/#endpoints) 对象上，
|
||||
表示时间戳（此时间戳以 RFC 3339 日期时间字符串格式存储。例如，“2018-10-22T19:32:52.1Z”）。
|
||||
这是某个 Pod 或 Service 对象发生变更并触发 Endpoints 对象变更的时间戳。
|
||||
|
||||
<!--
|
||||
### control-plane.alpha.kubernetes.io/leader (deprecated) {#control-plane-alpha-kubernetes-io-leader}
|
||||
|
||||
|
|
@ -2518,7 +2792,7 @@ Example: `batch.kubernetes.io/controller-uid: "$UID"`
|
|||
Used on: Jobs and Pods controlled by Jobs
|
||||
|
||||
This label is used as a programmatic way to get all Pods corresponding to a Job.
|
||||
The `controller-uid` is a unique identifer that gets set in the `selector` field so the Job
|
||||
The `controller-uid` is a unique identifier that gets set in the `selector` field so the Job
|
||||
controller can get all the corresponding Pods.
|
||||
-->
|
||||
### batch.kubernetes.io/controller-uid {#batchkubernetesio-controller-uid}
|
||||
|
|
@ -3597,7 +3871,7 @@ Used on: Service
|
|||
用于：Service
|
||||
|
||||
<!--
|
||||
The AWS load balancer controller uses this annotation to specify a comma seperated list
|
||||
The AWS load balancer controller uses this annotation to specify a comma separated list
|
||||
of security groups you want to attach to an AWS load balancer. Both name and ID of security
|
||||
are supported where name matches a `Name` tag, not the `groupName` attribute.
|
||||
|
||||
|
|
@ -3796,6 +4070,44 @@ details.
|
|||
参阅 AWS 关于此主题的文档以了解更多细节。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
### service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset (deprecated) {#service-beta-kubernetes-azure-load-balancer-disble-tcp-reset}
|
||||
|
||||
Example: `service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset: "false"`
|
||||
|
||||
Used on: Service
|
||||
-->
|
||||
### service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset（已弃用） {#service-beta-kubernetes-azure-load-balancer-disble-tcp-reset}
|
||||
|
||||
例子：`service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset: "false"`
|
||||
|
||||
用于：Service
|
||||
|
||||
<!--
|
||||
This annotation only works for Azure standard load balancer backed service.
|
||||
This annotation is used on the Service to specify whether the load balancer
|
||||
should disable or enable TCP reset on idle timeout. If enabled, it helps
|
||||
applications to behave more predictably, to detect the termination of a connection,
|
||||
remove expired connections and initiate new connections.
|
||||
You can set the value to be either true or false.
|
||||
-->
|
||||
此注解仅适用于由 Azure 标准负载均衡器支持的服务。
|
||||
此注解用于指定负载均衡器是否应在空闲超时时禁用或启用 TCP 重置。
|
||||
如果启用，它有助于提升应用行为的可预测度、检测连接的终止以及移除过期的连接并发起新的连接等。
|
||||
你可以将值设置为 true 或 false。
|
||||
|
||||
<!--
|
||||
See [Load Balancer TCP Reset](https://learn.microsoft.com/en-gb/azure/load-balancer/load-balancer-tcp-reset) for more information.
|
||||
-->
|
||||
更多细节参阅[负载均衡器 TCP 重置](https://learn.microsoft.com/zh-cn/azure/load-balancer/load-balancer-tcp-reset)。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
This annotation is deprecated.
|
||||
-->
|
||||
此注解已弃用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### pod-security.kubernetes.io/enforce
|
||||
|
||||
|
|
@ -4171,6 +4483,7 @@ Starting in v1.16, this annotation was removed in favor of
|
|||
- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
- [`validation.policy.admission.k8s.io/validation_failure`](/docs/reference/labels-annotations-taints/audit-annotations/#validation-policy-admission-k8s-io-validation-failure)
|
||||
|
||||
See more details on [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/).
|
||||
-->
|
||||
|
|
@ -4181,6 +4494,7 @@ See more details on [Audit Annotations](/docs/reference/labels-annotations-taint
|
|||
- [`pod-security.kubernetes.io/audit-violations`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
- [`validation.policy.admission.k8s.io/validation_failure`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#validation-policy-admission-k8s-io-validation-failure)
|
||||
|
||||
在[审计注解](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/)页面上查看更多详细信息。
|
||||
|
||||
|
|
|
|||
|
|
@ -93,8 +93,8 @@ CEL 表达式示例：
|
|||
| `self.metadata.name == 'singleton'` | Validate that an object's name matches a specific value (making it a singleton) |
|
||||
| `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint |
|
||||
| `self.names.size() == self.details.size() && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet |
|
||||
| `self.details.all(key, key.matches('^[a-zA-Z]*$')` | Validate the keys of the 'details' map |
|
||||
| `self.details.all(key, self.details[key].matches('^[a-zA-Z]*$')` | Validate the values of the 'details' map |
|
||||
| `self.details.all(key, key.matches('^[a-zA-Z]*$'))` | Validate the keys of the 'details' map |
|
||||
| `self.details.all(key, self.details[key].matches('^[a-zA-Z]*$'))` | Validate the values of the 'details' map |
|
||||
{{< /table >}}
|
||||
-->
|
||||
{{< table caption="CEL 表达式例子和每个表达式的用途" >}}
|
||||
|
|
@ -111,8 +111,8 @@ CEL 表达式示例：
|
|||
| `self.metadata.name == 'singleton'` | 验证某对象的名称与特定的值匹配（使其成为一个特例） |
|
||||
| `self.set1.all(e, !(e in self.set2))` | 验证两个 listSet 不相交 |
|
||||
| `self.names.size() == self.details.size() && self.names.all(n, n in self.details)` | 验证 'details' 映射是由 'names' listSet 中的各项键入的 |
|
||||
| `self.details.all(key, key.matches('^[a-zA-Z]*$')` | 验证 'details' 映射的主键 |
|
||||
| `self.details.all(key, self.details[key].matches('^[a-zA-Z]*$')` | 验证 'details' 映射的值 |
|
||||
| `self.details.all(key, key.matches('^[a-zA-Z]*$'))` | 验证 'details' 映射的主键 |
|
||||
| `self.details.all(key, self.details[key].matches('^[a-zA-Z]*$'))` | 验证 'details' 映射的值 |
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -473,11 +473,11 @@ and not require this setting on kubelet any longer.
|
|||
<!--
|
||||
This section contains the necessary steps to install CRI-O as a container runtime.
|
||||
|
||||
To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/cri-o/blob/main/install.md#readme).
|
||||
To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/packaging/blob/main/README.md#usage).
|
||||
-->
|
||||
本节包含安装 CRI-O 作为容器运行时的必要步骤。
|
||||
|
||||
要安装 CRI-O，请按照 [CRI-O 安装说明](https://github.com/cri-o/cri-o/blob/main/install.md#readme)执行操作。
|
||||
要安装 CRI-O，请按照 [CRI-O 安装说明](https://github.com/cri-o/packaging/blob/main/README.md#usage)执行操作。
|
||||
|
||||
<!--
|
||||
#### cgroup driver
|
||||
|
|
|
|||
|
|
@ -0,0 +1,278 @@
|
|||
---
|
||||
title: 将 PersistentVolume 的访问模式更改为 ReadWriteOncePod
|
||||
content_type: task
|
||||
weight: 90
|
||||
min-kubernetes-server-version: v1.22
|
||||
---
|
||||
<!--
|
||||
title: Change the Access Mode of a PersistentVolume to ReadWriteOncePod
|
||||
content_type: task
|
||||
weight: 90
|
||||
min-kubernetes-server-version: v1.22
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to change the access mode on an existing PersistentVolume to
|
||||
use `ReadWriteOncePod`.
|
||||
-->
|
||||
本文演示了如何将现有 PersistentVolume 的访问模式更改为使用 `ReadWriteOncePod`。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `ReadWriteOncePod` access mode graduated to stable in the Kubernetes v1.29
|
||||
release. If you are running a version of Kubernetes older than v1.29, you might
|
||||
need to enable a feature gate. Check the documentation for your version of
|
||||
Kubernetes.
|
||||
-->
|
||||
`ReadWriteOncePod` 访问模式在 Kubernetes v1.29 版本中已进阶至 Stable。
|
||||
如果你运行的 Kubernetes 版本早于 v1.29，你可能需要启用一个特性门控。
|
||||
请查阅你所用 Kubernetes 版本的文档。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `ReadWriteOncePod` access mode is only supported for
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} volumes.
|
||||
To use this volume access mode you will need to update the following
|
||||
[CSI sidecars](https://kubernetes-csi.github.io/docs/sidecar-containers.html)
|
||||
to these versions or greater:
|
||||
-->
|
||||
`ReadWriteOncePod` 访问模式仅支持 {{< glossary_tooltip text="CSI" term_id="csi" >}} 卷。
|
||||
要使用这种卷访问模式，你需要更新以下
|
||||
[CSI 边车](https://kubernetes-csi.github.io/docs/sidecar-containers.html)至下述版本或更高版本：
|
||||
|
||||
* [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0)
|
||||
* [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0)
|
||||
* [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Why should I use `ReadWriteOncePod`?
|
||||
|
||||
Prior to Kubernetes v1.22, the `ReadWriteOnce` access mode was commonly used to
|
||||
restrict PersistentVolume access for workloads that required single-writer
|
||||
access to storage. However, this access mode had a limitation: it restricted
|
||||
volume access to a single *node*, allowing multiple pods on the same node to
|
||||
read from and write to the same volume simultaneously. This could pose a risk
|
||||
for applications that demand strict single-writer access for data safety.
|
||||
|
||||
If ensuring single-writer access is critical for your workloads, consider
|
||||
migrating your volumes to `ReadWriteOncePod`.
|
||||
-->
|
||||
## 我为什么要使用 `ReadWriteOncePod`？ {#why-should-i-use-readwriteoncepod}
|
||||
|
||||
在 Kubernetes v1.22 之前，`ReadWriteOnce`
|
||||
访问模式通常用于限制需要单个写者存储访问模式的工作负载对 PersistentVolume 的访问。
|
||||
然而，这种访问模式有一个限制：它要求只能从单个**节点**上访问卷，但允许同一节点上的多个 Pod 同时读写同一个卷。
|
||||
对于需要严格遵循单个写者访问模式以确保数据安全的应用，这种模式可能形成风险。
|
||||
|
||||
如果确保单个写者访问模式对于你的工作负载至关重要，请考虑将你的卷迁移到 `ReadWriteOncePod`。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Migrating existing PersistentVolumes
|
||||
|
||||
If you have existing PersistentVolumes, they can be migrated to use
|
||||
`ReadWriteOncePod`. Only migrations from `ReadWriteOnce` to `ReadWriteOncePod`
|
||||
are supported.
|
||||
|
||||
In this example, there is already a `ReadWriteOnce` "cat-pictures-pvc"
|
||||
PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume,
|
||||
and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim.
|
||||
-->
|
||||
## 迁移现有 PersistentVolume {#migrating-existing-persistentvolumes}
|
||||
|
||||
如果你有一些 PersistentVolume，可以将它们迁移为使用 `ReadWriteOncePod`。
|
||||
系统仅支持从 `ReadWriteOnce` 迁移到 `ReadWriteOncePod`。
|
||||
|
||||
在此示例中，已经有一个 `ReadWriteOnce` 的 "cat-pictures-pvc" PersistentVolumeClaim
|
||||
被绑定到了 "cat-pictures-pv" PersistentVolume，还有一个使用此
|
||||
PersistentVolumeClaim 的 "cat-pictures-writer" Deployment。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If your storage plugin supports
|
||||
[Dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/),
|
||||
the "cat-picutres-pv" will be created for you, but its name may differ. To get
|
||||
your PersistentVolume's name run:
|
||||
-->
|
||||
如果你的存储插件支持[动态制备](/zh-cn/docs/concepts/storage/dynamic-provisioning/)，
|
||||
系统将为你创建 "cat-pictures-pv"，但其名称可能不同。
|
||||
要获取你的 PersistentVolume 的名称，请运行以下命令：
|
||||
|
||||
```shell
|
||||
kubectl get pvc cat-pictures-pvc -o jsonpath='{.spec.volumeName}'
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
And you can view the PVC before you make changes. Either view the manifest
|
||||
locally, or run `kubectl get pvc <name-of-pvc> -o yaml`. The output is similar
|
||||
to:
|
||||
-->
|
||||
你可以在进行更改之前查看 PVC。你可以在本地查看清单，
|
||||
或运行 `kubectl get pvc <PVC 名称> -o yaml`。这条命令的输出类似于：
|
||||
|
||||
```yaml
|
||||
# cat-pictures-pvc.yaml
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: cat-pictures-pvc
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
<!--
|
||||
Here's an example Deployment that relies on that PersistentVolumeClaim:
|
||||
-->
|
||||
以下是一个依赖于此 PersistentVolumeClaim 的 Deployment 示例：
|
||||
|
||||
```yaml
|
||||
# cat-pictures-writer-deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: cat-pictures-writer
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: cat-pictures-writer
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: cat-pictures-writer
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.14.2
|
||||
ports:
|
||||
- containerPort: 80
|
||||
volumeMounts:
|
||||
- name: cat-pictures
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: cat-pictures
|
||||
persistentVolumeClaim:
|
||||
claimName: cat-pictures-pvc
|
||||
readOnly: false
|
||||
```
|
||||
|
||||
<!--
|
||||
As a first step, you need to edit your PersistentVolume's
|
||||
`spec.persistentVolumeReclaimPolicy` and set it to `Retain`. This ensures your
|
||||
PersistentVolume will not be deleted when you delete the corresponding
|
||||
PersistentVolumeClaim:
|
||||
-->
|
||||
第一步，你需要编辑 PersistentVolume 的 `spec.persistentVolumeReclaimPolicy`
|
||||
并将其设置为 `Retain`。此字段确保你在删除相应的 PersistentVolumeClaim 时不会删除 PersistentVolume：
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
Next you need to stop any workloads that are using the PersistentVolumeClaim
|
||||
bound to the PersistentVolume you want to migrate, and then delete the
|
||||
PersistentVolumeClaim. Avoid making any other changes to the
|
||||
PersistentVolumeClaim, such as volume resizes, until after the migration is
|
||||
complete.
|
||||
|
||||
Once that is done, you need to clear your PersistentVolume's `spec.claimRef.uid`
|
||||
to ensure PersistentVolumeClaims can bind to it upon recreation:
|
||||
-->
|
||||
接下来，你需要停止正在使用绑定到你要迁移的这个 PersistentVolume 上的
|
||||
PersistentVolumeClaim 的所有工作负载，然后删除该 PersistentVolumeClaim。
|
||||
在迁移完成之前，不要对 PersistentVolumeClaim 进行任何其他更改，例如调整卷的大小。
|
||||
|
||||
完成后，你需要清除 PersistentVolume 的 `spec.claimRef.uid`
|
||||
以确保在重新创建时 PersistentVolumeClaim 能够绑定到它：
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=0 deployment cat-pictures-writer
|
||||
kubectl delete pvc cat-pictures-pvc
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
After that, replace the PersistentVolume's list of valid access modes to be
|
||||
(only) `ReadWriteOncePod`:
|
||||
-->
|
||||
之后，将 PersistentVolume 的有效访问模式列表替换为（仅）`ReadWriteOncePod`：
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}'
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `ReadWriteOncePod` access mode cannot be combined with other access modes.
|
||||
Make sure `ReadWriteOncePod` is the only access mode on the PersistentVolume
|
||||
when updating, otherwise the request will fail.
|
||||
-->
|
||||
`ReadWriteOncePod` 访问模式不能与其他访问模式结合使用。
|
||||
你要确保在更新时 `ReadWriteOncePod` 是 PersistentVolume 上的唯一访问模式，否则请求将失败。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Next you need to modify your PersistentVolumeClaim to set `ReadWriteOncePod` as
|
||||
the only access mode. You should also set the PersistentVolumeClaim's
|
||||
`spec.volumeName` to the name of your PersistentVolume to ensure it binds to
|
||||
this specific PersistentVolume.
|
||||
|
||||
Once this is done, you can recreate your PersistentVolumeClaim and start up your
|
||||
workloads:
|
||||
-->
|
||||
接下来，你需要修改 PersistentVolumeClaim，将 `ReadWriteOncePod` 设置为唯一的访问模式。
|
||||
你还应将 PersistentVolumeClaim 的 `spec.volumeName` 设置为 PersistentVolume 的名称，
|
||||
以确保其绑定到特定的 PersistentVolume。
|
||||
|
||||
完成后，你可以重新创建你的 PersistentVolumeClaim 并启动你的工作负载：
|
||||
|
||||
<!--
|
||||
# IMPORTANT: Make sure to edit your PVC in cat-pictures-pvc.yaml before applying. You need to:
|
||||
# - Set ReadWriteOncePod as the only access mode
|
||||
# - Set spec.volumeName to "cat-pictures-pv"
|
||||
-->
|
||||
```shell
|
||||
# 重要提示：在 apply 操作之前必须编辑在 cat-pictures-pvc.yaml 中的 PVC。你需要：
|
||||
# - 将 ReadWriteOncePod 设置为唯一的访问模式
|
||||
# - 将 spec.volumeName 设置为 "cat-pictures-pv"
|
||||
|
||||
kubectl apply -f cat-pictures-pvc.yaml
|
||||
kubectl apply -f cat-pictures-writer-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Lastly you may edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy`
|
||||
and set to it back to `Delete` if you previously changed it.
|
||||
-->
|
||||
最后，你可以编辑 PersistentVolume 的 `spec.persistentVolumeReclaimPolicy` 并将其设置回 `Delete`，
|
||||
如果你之前更改了这个字段的话。
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
|
||||
* Learn more about [Configuring a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)
|
||||
-->
|
||||
* 进一步了解 [PersistentVolume](/zh-cn/docs/concepts/storage/persistent-volumes/)。
|
||||
* 进一步了解 [PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
|
||||
* 进一步了解[配置 Pod 以使用 PersistentVolume 作为存储](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
|
||||
|
|
@ -156,15 +156,15 @@ kubeadm 将控制平面组件作为位于 `/etc/kubernetes/manifests`
|
|||
<!--
|
||||
Such changes may include:
|
||||
- `extraArgs` - requires updating the list of flags passed to a component container
|
||||
- `extraMounts` - requires updated the volume mounts for a component container
|
||||
- `*SANs` - requires writing new certificates with updated Subject Alternative Names.
|
||||
- `extraVolumes` - requires updating the volume mounts for a component container
|
||||
- `*SANs` - requires writing new certificates with updated Subject Alternative Names
|
||||
|
||||
Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`.
|
||||
-->
|
||||
|
||||
此类更改可能包括:
|
||||
- `extraArgs` - 需要更新传递给组件容器的标志列表
|
||||
- `extraMounts` - 需要更新组件容器的卷挂载
|
||||
- `extraVolumes` - 需要更新组件容器的卷挂载
|
||||
- `*SANs` - 需要使用更新的主题备用名称编写新证书
|
||||
|
||||
在继续进行这些更改之前，请确保你已备份目录 `/etc/kubernetes/`。
|
||||
|
|
|
|||
|
|
@ -95,9 +95,9 @@ AWS EBS volumes have a 1Gi minimum requirement.
|
|||
例如，AWS EBS volumes 的最低要求为 1Gi。
|
||||
|
||||
<!--
|
||||
## StorageQuota to limit PVC count and cumulative storage capacity
|
||||
## ResourceQuota to limit PVC count and cumulative storage capacity
|
||||
-->
|
||||
## 使用 StorageQuota 限制 PVC 数目和累计存储容量
|
||||
## 使用 ResourceQuota 限制 PVC 数目和累计存储容量
|
||||
|
||||
<!--
|
||||
Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed
|
||||
|
|
|
|||
|
|
@ -215,10 +215,10 @@ credspec:
|
|||
DomainJoinConfig:
|
||||
DnsName: contoso.com # DNS Domain Name
|
||||
DnsTreeName: contoso.com # DNS Domain Name Root
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID of the Domain
|
||||
MachineAccountName: WebApp1 # Username of the GMSA account
|
||||
NetBiosName: CONTOSO # NETBIOS Domain Name
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID of GMSA
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID of the Domain
|
||||
```
|
||||
-->
|
||||
下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约：
|
||||
|
|
@ -240,10 +240,10 @@ credspec:
|
|||
DomainJoinConfig:
|
||||
DnsName: contoso.com # DNS 域名
|
||||
DnsTreeName: contoso.com # DNS 域名根
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # 域名的 GUID
|
||||
MachineAccountName: WebApp1 # GMSA 账号的用户名
|
||||
NetBiosName: CONTOSO # NETBIOS 域名
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSA 的 SID
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # 域名的 SID
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -467,7 +467,7 @@ there are a few troubleshooting steps you can take.
|
|||
|
||||
<!--
|
||||
First, make sure the credspec has been passed to the Pod. To do this you will need
|
||||
to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
-->
|
||||
首先，确保 credspec 已传递给 Pod。为此，你需要先运行 `exec`
|
||||
进入到你的一个 Pod 中并检查 `nltest.exe /parentdomain` 命令的输出。
|
||||
|
|
|
|||
|
|
@ -13,6 +13,8 @@ weight: 140
|
|||
<!--
|
||||
This page shows how to configure liveness, readiness and startup probes for containers.
|
||||
|
||||
For more information about probes, see [Liveness, Readiness and Startup Probes](/docs/concepts/configuration/liveness-readiness-startup-probes)
|
||||
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses
|
||||
liveness probes to know when to restart a container. For example, liveness
|
||||
probes could catch a deadlock, where an application is running, but unable to
|
||||
|
|
@ -21,6 +23,9 @@ application more available despite bugs.
|
|||
-->
|
||||
这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。
|
||||
|
||||
有关探针的更多信息，请参阅
|
||||
[Liveness、Readiness 和 Startup 探针](/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes)。
|
||||
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
|
||||
使用存活探针来确定什么时候要重启容器。
|
||||
例如，存活探针可以探测到应用死锁（应用在运行，但是无法继续执行后面的步骤）情况。
|
||||
|
|
|
|||
|
|
@ -421,12 +421,12 @@ token: ...
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The content of `token` is elided here.
|
||||
The content of `token` is omitted here.
|
||||
|
||||
Take care not to display the contents of a `kubernetes.io/service-account-token`
|
||||
Secret somewhere that your terminal / computer screen could be seen by an onlooker.
|
||||
-->
|
||||
这里将 `token` 的内容抹去了。
|
||||
这里将 `token` 的内容省略了。
|
||||
|
||||
注意在你的终端或者计算机屏幕可能被旁观者看到的场合，不要显示
|
||||
`kubernetes.io/service-account-token` 的内容。
|
||||
|
|
|
|||
|
|
@ -124,7 +124,8 @@ When creating a debugging session on a Node, keep in mind that:
|
|||
* Although the container runs in the host IPC, Network, and PID namespaces,
|
||||
the pod isn't privileged. This means that reading some process information might fail
|
||||
because access to that information is restricted to superusers. For example, `chroot /host` will fail.
|
||||
If you need a privileged pod, create it manually.
|
||||
If you need a privileged pod, create it manually or use the `--profile=sysadmin` flag.
|
||||
* By applying [Debugging Profiles](/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles), you can set specific properties such as [securityContext](/docs/tasks/configure-pod-container/security-context/) to a debugging Pod.
|
||||
-->
|
||||
当在节点上创建一个调试会话时，需谨记：
|
||||
|
||||
|
|
@ -132,7 +133,9 @@ When creating a debugging session on a Node, keep in mind that:
|
|||
* 节点的根文件系统将被挂载在 `/host`。
|
||||
* 尽管容器运行在主机 IPC、Network 和 PID 名字空间中，但 Pod 没有特权。
|
||||
这意味着读取某些进程信息可能会失败，这是因为访问这些信息仅限于超级用户 (superuser)。
|
||||
例如，`chroot /host` 将失败。如果你需要一个有特权的 Pod，请手动创建。
|
||||
例如，`chroot /host` 将失败。如果你需要一个有特权的 Pod，请手动创建或使用 `--profile=sysadmin` 标志。
|
||||
* 通过应用[调试配置](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)，
|
||||
你可以为调试 Pod 设置特定的属性，例如 [securityContext](/zh-cn/docs/tasks/configure-pod-container/security-context/)。
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -2660,7 +2660,6 @@ may also be used with field selectors when included in the `spec.versions[*].sel
|
|||
-->
|
||||
#### 自定义资源的可选字段 {#crd-selectable-fields}
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.30" >}}
|
||||
{{< feature-state feature_gate_name="CustomResourceFieldSelectors" >}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -40,6 +40,23 @@ Install [`kubectl`](/docs/tasks/tools/#kubectl).
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
Ensure that your cluster has the `StorageVersionMigrator` and `InformerResourceVersion`
|
||||
[feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
enabled. You will need control plane administrator access to make that change.
|
||||
|
||||
Enable storage version migration REST api by setting runtime config
|
||||
`storagemigration.k8s.io/v1alpha1` to `true` for the API server. For more information on
|
||||
how to do that,
|
||||
read [enable or disable a Kubernetes API](/docs/tasks/administer-cluster/enable-disable-api/).
|
||||
-->
|
||||
确保你的集群启用了 `StorageVersionMigrator` 和 `InformerResourceVersion`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
你需要有控制平面管理员权限才能执行此项变更。
|
||||
|
||||
在 API 服务器上将运行时配置 `storagemigration.k8s.io/v1alpha1` 设为 `true`，启用存储版本迁移 REST API。
|
||||
有关如何执行此操作的更多信息，请阅读[启用或禁用 Kubernetes API](/zh-cn/docs/tasks/administer-cluster/enable-disable-api/)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -132,9 +132,9 @@ service/php-apache created
|
|||
<!--
|
||||
## Create the HorizontalPodAutoscaler {#create-horizontal-pod-autoscaler}
|
||||
|
||||
Now that the server is running, create the autoscaler using `kubectl`. There is
|
||||
Now that the server is running, create the autoscaler using `kubectl`. The
|
||||
[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) subcommand,
|
||||
part of `kubectl`, that helps you do this.
|
||||
part of `kubectl`, helps you do this.
|
||||
|
||||
You will shortly run a command that creates a HorizontalPodAutoscaler that maintains
|
||||
between 1 and 10 replicas of the Pods controlled by the php-apache Deployment that
|
||||
|
|
@ -420,12 +420,12 @@ status:
|
|||
Notice that the `targetCPUUtilizationPercentage` field has been replaced with an array called `metrics`.
|
||||
The CPU utilization metric is a *resource metric*, since it is represented as a percentage of a resource
|
||||
specified on pod containers. Notice that you can specify other resource metrics besides CPU. By default,
|
||||
the only other supported resource metric is memory. These resources do not change names from cluster
|
||||
the only other supported resource metric is `memory`. These resources do not change names from cluster
|
||||
to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
|
||||
-->
|
||||
需要注意的是，`targetCPUUtilizationPercentage` 字段已经被名为 `metrics` 的数组所取代。
|
||||
CPU 利用率这个度量指标是一个 **resource metric**（资源度量指标），因为它表示容器上指定资源的百分比。
|
||||
除 CPU 外，你还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。
|
||||
除 CPU 外，你还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为 `memory`。
|
||||
只要 `metrics.k8s.io` API 存在，这些资源度量指标就是可用的，并且他们不会在不同的 Kubernetes 集群中改变名称。
|
||||
|
||||
<!--
|
||||
|
|
@ -437,6 +437,16 @@ setting the corresponding `target.averageValue` field instead of the `target.ave
|
|||
`Utilization` 替换成 `AverageValue`，同时设置 `target.averageValue`
|
||||
而非 `target.averageUtilization` 的值。
|
||||
|
||||
```
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: memory
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 500Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
|
||||
object metrics. These metrics may have names which are cluster specific, and require a more
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ metadata:
|
|||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: hello-world.example
|
||||
http:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: rro
|
||||
spec:
|
||||
volumes:
|
||||
- name: mnt
|
||||
hostPath:
|
||||
# tmpfs 被挂载到 /mnt/tmpfs 上
|
||||
path: /mnt
|
||||
containers:
|
||||
- name: busybox
|
||||
image: busybox
|
||||
args: ["sleep", "infinity"]
|
||||
volumeMounts:
|
||||
# /mnt-rro/tmpfs 不可写入
|
||||
- name: mnt
|
||||
mountPath: /mnt-rro
|
||||
readOnly: true
|
||||
mountPropagation: None
|
||||
recursiveReadOnly: Enabled
|
||||
# /mnt-ro/tmpfs 可写入
|
||||
- name: mnt
|
||||
mountPath: /mnt-ro
|
||||
readOnly: true
|
||||
# /mnt-rw/tmpfs 可写入
|
||||
- name: mnt
|
||||
mountPath: /mnt-rw
|
||||
|
|
@ -19,28 +19,6 @@
|
|||
s.parentNode.insertBefore(gcse, s);
|
||||
}
|
||||
|
||||
window.getPaginationAnchors = (pages) => {
|
||||
var pageAnchors = '', searchTerm = window.location.search.split("=")[1].split("&")[0].replace(/%20/g, ' ');
|
||||
var currentPage = window.location.search.split("=")[2];
|
||||
currentPage = (!currentPage) ? 1 : currentPage.split("&")[0];
|
||||
|
||||
for(var i = 1; i <= 10; i++){
|
||||
if(i > pages) break;
|
||||
pageAnchors += '<a class="bing-page-anchor" href="/search/?q='+searchTerm+'&page='+i+'">';
|
||||
pageAnchors += (currentPage == i) ? '<b>'+i+'</b>' : i;
|
||||
pageAnchors += '</a>';
|
||||
}
|
||||
return pageAnchors;
|
||||
}
|
||||
|
||||
window.getResultMarkupString = (ob) => {
|
||||
return '<div class="bing-result">'
|
||||
+ '<div class="bing-result-name"><a href="'+ob.url+'">'+ob.name+'</a></div>'
|
||||
+ '<div class="bing-result-url">'+ob.displayUrl+'</div>'
|
||||
+ '<div class="bing-result-snippet">'+ob.snippet+'</div>'
|
||||
+'</div>';
|
||||
}
|
||||
|
||||
window.renderPageFindSearchResults = () => {
|
||||
let urlParams = new URLSearchParams(window.location.search);
|
||||
let searchTerm = urlParams.get("q") || "";
|
||||
|
|
|
|||
Loading…
Reference in New Issue