diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md index b372e7e7b4..a896d0f8c9 100644 --- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md +++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md @@ -7,11 +7,16 @@ slug: are-you-ready-for-dockershim-removal **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano. +{{% alert color="info" title="Poll closed" %}} +This poll closed on January 7, 2022. +{{% /alert %}} + Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). Our current plan is to remove dockershim from the Kubernetes codebase soon. We are looking for feedback from you whether you are ready for dockershim removal and to ensure that you are ready when the time comes. -**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**. + +Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8 The dockershim component that enables Docker as a Kubernetes container runtime is being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) @@ -25,7 +30,7 @@ are still not ready: [migrating telemetry and security agents](/docs/tasks/admin At this point, we believe that there is feature parity between Docker and the other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/) and are running production workload using these different runtimes. The plan of -record today is that dockershim will be removed in version 1.24, slated for +record today is that dockershim will be removed in version 1.24, slated for release around April of next year. For those developing or running alpha and beta versions, dockershim will be removed in December at the beginning of the 1.24 release development cycle. @@ -33,7 +38,7 @@ beta versions, dockershim will be removed in December at the beginning of the There is only one month left to give us feedback. We want you to tell us how ready you are. -**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)** +We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8 To better understand preparedness for the dockershim removal, our survey is asking the version of Kubernetes you are currently using, and an estimate of when you think you will adopt Kubernetes 1.24. All the aggregated information diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md new file mode 100644 index 0000000000..07f33b8b80 --- /dev/null +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -0,0 +1,103 @@ +--- +layout: blog +title: "Kubernetes is Moving on From Dockershim: Commitments and Next Steps" +date: 2022-01-07 +slug: kubernetes-is-moving-on-from-dockershim +--- + +**Authors:** Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google) + +Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited +to reaffirm our community values by supporting open source container runtimes, +enabling a smaller kubelet, and increasing engineering velocity for teams using +Kubernetes. If you [use Docker Engine as a container runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) +for your Kubernetes cluster, get ready to migrate in 1.24! To check if you're +affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). + +## Why we’re moving away from dockershim + +Docker was the first container runtime used by Kubernetes. This is one of the +reasons why Docker is so familiar to many Kubernetes users and enthusiasts. +Docker support was hardcoded into Kubernetes – a component the project refers to +as dockershim. +As containerization became an industry standard, the Kubernetes project added support +for additional runtimes. This culminated in the implementation of the +container runtime interface (CRI), letting system components (like the kubelet) +talk to container runtimes in a standardized way. As a result, dockershim became +an anomaly in the Kubernetes project. +Dependencies on Docker and dockershim have crept into various tools +and projects in the CNCF ecosystem ecosystem, resulting in fragile code. + +By removing the +dockershim CRI, we're embracing the first value of CNCF: "[Fast is better than +slow](https://github.com/cncf/foundation/blob/master/charter.md#3-values)". +Stay tuned for future communications on the topic! + +## Deprecation timeline + +We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020. Full removal is targeted +in Kubernetes 1.24, in April 2022. This timeline +aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior), +which states that deprecated behaviors must function for at least 1 year +after their announced deprecation. + +We'll support Kubernetes version 1.23, which includes +dockershim, for another year in the Kubernetes project. For managed +Kubernetes providers, vendor support is likely to last even longer, but this is +dependent on the companies themselves. Regardless, we're confident all cluster operations will have +time to migrate. If you have more questions about the dockershim removal, refer +to the [Dockershim Deprecation FAQ](/dockershim). + +We asked you whether you feel prepared for the migration from dockershim in this +survey: [Are you ready for Dockershim removal](/blog/2021/11/12/are-you-ready-for-dockershim-removal/). +We had over 600 responses. To everybody who took time filling out the survey, +thank you. + +The results show that we still have a lot of ground to cover to help you to +migrate smoothly. Other container runtimes exist, and have been promoted +extensively. However, many users told us they still rely on dockershim, +and sometimes have dependencies that need to be re-worked. Some of these +dependencies are outside of your control. Based on your feedback, here are some +of the steps we are taking to help. + +## Our next steps + +Based on the feedback you provided: + +- CNCF and the 1.24 release team are committed to delivering documentation in + time for the 1.24 release. This includes more informative blog posts like this + one, updating existing code samples, tutorials, and tasks, and producing a + migration guide for cluster operators. +- We are reaching out to the rest of the CNCF community to help prepare them for + this change. + +If you're part of a project with dependencies on dockershim, or if you're +interested in helping with the migration effort, please join us! There's always +room for more contributors, whether to our transition tools or to our +documentation. To get started, say hello in the +[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G) +channel on [Kubernetes Slack](https://slack.kubernetes.io/)! + +## Final thoughts + +As a project, we've already seen cluster operators increasingly adopt other +container runtimes through 2021. +We believe there are no major blockers to migration. The steps we're taking to +improve the migration experience will light the path more clearly for you. + +We understand that migration from dockershim is yet another action you may need to +do to keep your Kubernetes infrastructure up to date. For most of you, this step +will be straightforward and transparent. In some cases, you will encounter +hiccups or issues. The community has discussed at length whether postponing the +dockershim removal would be helpful. For example, we recently talked about it in +the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid) +and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx). +We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it +once in 2021 because the adoption rate of other +runtimes was lower than we wanted, which also gave us more time to identify +potential blocking issues. + +At this point, we believe that the value that you (and Kubernetes) gain from +dockershim removal makes up for the migration effort you'll have. Start planning +now to avoid surprises. We'll have more updates and guides before Kubernetes +1.24 is released. diff --git a/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md new file mode 100644 index 0000000000..4c969ff50c --- /dev/null +++ b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md @@ -0,0 +1,106 @@ +--- +layout: blog +title: "Meet Our Contributors - APAC (India region)" +date: 2022-01-10T12:00:00+0000 +slug: meet-our-contributors-india-ep-01 +canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/ +--- + +**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) + +**Editor:** [Priyanka Saggu](https://psaggu.com) + +--- + +Good day, everyone 👋 + +Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series. + + +In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives. + +💫 *Let's get started, so without further ado…* + + +## [Arsh Sharma](https://github.com/RinkiyaKeDad) + +Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project. + +He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture. + +To the newcomers, Arsh helps plan their early contributions sustainably. + +> _I would encourage folks to contribute in a way that's sustainable. What I mean by that +> is that it's easy to be very enthusiastic early on and take up more stuff than one can +> actually handle. This can often lead to burnout in later stages. It's much more sustainable +> to work on things iteratively._ + +## [Kunal Kushwaha](https://github.com/kunal-kushwaha) + +Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle. + +At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. + +As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer. + + +> _I believe if you find yourself in a place where you do not know much about the +> project, that's a good thing because now you can learn while contributing and the +> community is there to help you. It has helped me a lot in gaining skills, meeting +> people from around the world and also helping them. You can learn on the go, +> you don't have to be an expert. Make sure to also check out no code contributions +> because being a beginner is a skill and you can bring new perspectives to the +> organisation._ + +## [Madhav Jivarajani](https://github.com/MadhavJivrajani) + + +Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience). + +Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129). + +In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc). + +> _I initially did not know much about Kubernetes. I joined because the community was +> super friendly. But what made me stay was not just the people, but the project itself. +> My solution to not feeling overwhelmed in the community was to gain as much context +> and knowledge into the topics that I was interested in and were being discussed. And +> as a result I continued to dig deeper into Kubernetes and the design of it. +> I am a systems nut & thus Kubernetes was an absolute goldmine for me._ + + +## [Rajas Kakodkar](https://github.com/rajaskakodkar) + +Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019. + +He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects. + +One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem. + +> _I enjoy contributing to Kubernetes not just because I get to work on +> cutting edge tech but more importantly because I get to work with +> awesome people and help in solving real world problems._ + +## [Rajula Vineet Reddy](https://github.com/rajula96reddy) + +Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles. + +He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject. + +According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community. + +> _I find the community very helpful and it's always_ +> “you get back as much as you contribute”. +> _The more involved you are, the more you will understand, get to learn and +> contribute new things._ +> +> _The first step to_ “come forward and start” _is hard. But it's all gonna be +> smooth after that. Just take that jump._ + +--- + +If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated. + + +We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 + diff --git a/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md new file mode 100644 index 0000000000..002b2bd531 --- /dev/null +++ b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md @@ -0,0 +1,44 @@ +--- +layout: blog +title: "Securing Admission Controllers" +date: 2022-01-19 +slug: secure-your-admission-controllers-and-webhooks +--- + +**Author:** Rory McCune (Aqua Security) + +[Admission control](/docs/reference/access-authn-authz/admission-controllers/) is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of ways including restricting the privileges of workloads and ensuring that images deployed to the cluster meet organization’s security requirements. + +However, as with any additional component added to a cluster, security risks can present themselves. A security risk example is if the deployment and management of the admission controller are not handled correctly. To help admission controller users and designers manage these risks appropriately, the [security documentation](https://github.com/kubernetes/community/tree/master/sig-security#security-docs) subgroup of SIG Security has spent some time developing a [threat model for admission controllers](https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control). This threat model looks at likely risks which may arise from the incorrect use of admission controllers, which could allow security policies to be bypassed, or even allow an attacker to get unauthorised access to the cluster. + +From the threat model, we developed a set of security best practices that should be adopted to ensure that cluster operators can get the security benefits of admission controllers whilst avoiding any risks from using them. + +## Admission controllers and good practices for security + +From the threat model, a couple of themes emerged around how to ensure the security of admission controllers. + +### Secure webhook configuration + +It’s important to ensure that any security component in a cluster is well configured and admission controllers are no different here. There are a couple of security best practices to consider when using admission controllers + +* **Correctly configured TLS for all webhook traffic**. Communications between the API server and the admission controller webhook should be authenticated and encrypted to ensure that attackers who may be in a network position to view or modify this traffic cannot do so. To achieve this access the API server and webhook must be using certificates from a trusted certificate authority so that they can validate their mutual identities +* **Only authenticated access allowed**. If an attacker can send an admission controller large numbers of requests, they may be able to overwhelm the service causing it to fail. Ensuring all access requires strong authentication should mitigate that risk. +* **Admission controller fails closed**. This is a security practice that has a tradeoff, so whether a cluster operator wants to configure it will depend on the cluster’s threat model. If an admission controller fails closed, when the API server can’t get a response from it, all deployments will fail. This stops attackers bypassing the admission controller by disabling it, but, can disrupt the cluster’s operation. As clusters can have multiple webhooks, one approach to hit a middle ground might be to have critical controls on a fail closed setups and less critical controls allowed to fail open. +* **Regular reviews of webhook configuration**. Configuration mistakes can lead to security issues, so it’s important that the admission controller webhook configuration is checked to make sure the settings are correct. This kind of review could be done automatically by an Infrastructure As Code scanner or manually by an administrator. + + +### Secure cluster configuration for admission control + +In most cases, the admission controller webhook used by a cluster will be installed as a workload in the cluster. As a result, it’s important to ensure that Kubernetes' security features that could impact its operation are well configured. + +* **Restrict [RBAC](/docs/reference/access-authn-authz/rbac/) rights**. Any user who has rights which would allow them to modify the configuration of the webhook objects or the workload that the admission controller uses could disrupt its operation. So it’s important to make sure that only cluster administrators have those rights. +* **Prevent privileged workloads**. One of the realities of container systems is that if a workload is given certain privileges, it will be possible to break out to the underlying cluster node and impact other containers on that node. Where admission controller services run in the cluster they’re protecting, it’s important to ensure that any requirement for privileged workloads is carefully reviewed and restricted as much as possible. +* **Strictly control external system access**. As a security service in a cluster admission controller systems will have access to sensitive information like credentials. To reduce the risk of this information being sent outside the cluster, [network policies](/docs/concepts/services-networking/network-policies/) should be used to restrict the admission controller services access to external networks. +* **Each cluster has a dedicated webhook**. Whilst it may be possible to have admission controller webhooks that serve multiple clusters, there is a risk when using that model that an attack on the webhook service would have a larger impact where it’s shared. Also where multiple clusters use an admission controller there will be increased complexity and access requirements, making it harder to secure. + + +### Admission controller rules + +A key element of any admission controller used for Kubernetes security is the rulebase it uses. The rules need to be able to accurately meet their goals avoiding false positive and false negative results. + +* **Regularly test and review rules**. Admission controller rules need to be tested to ensure their accuracy. They also need to be regularly reviewed as the Kubernetes API will change with each new version, and rules need to be assessed with each Kubernetes release to understand any changes that may be required to keep them up to date. diff --git a/content/en/docs/concepts/architecture/cri.md b/content/en/docs/concepts/architecture/cri.md index e8391ca34b..02f6d8a199 100644 --- a/content/en/docs/concepts/architecture/cri.md +++ b/content/en/docs/concepts/architecture/cri.md @@ -15,7 +15,7 @@ each Node in your cluster, so that the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch {{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers. -{{< glossary_definition term_id="container-runtime-interface" length="all" >}} +{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="container-runtime-interface" length="all" >}} diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 0974089f8d..74e81092ae 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -33,7 +33,7 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP 1. The kubelet on a node self-registers to the control plane 2. You (or another human user) manually add a Node object -After you create a Node object, or the kubelet on a node self-registers, the +After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest: diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index ee7793d004..ca026b204f 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -79,7 +79,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. @@ -104,10 +104,6 @@ network complexity required to deploy Kubernetes at scale within AWS. [Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking. Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks. -### Contiv - -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. - ### Contrail / Tungsten Fabric [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. @@ -130,6 +126,10 @@ With this toolset DANM is able to provide multiple separated network interfaces, network that satisfies the Kubernetes requirements. Many people have reported success with Flannel and Kubernetes. +### Hybridnet + +[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity. + ### Jaguar [Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod. diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index f14f78b13b..8b201e70e6 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -1,7 +1,6 @@ --- -reviewers: title: Device Plugins -description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup. +description: Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory. content_type: concept weight: 20 --- @@ -48,12 +47,14 @@ For example, after a device plugin registers `hardware-vendor.example/foo` with and reports two healthy devices on a node, the node status is updated to advertise that the node has 2 "Foo" devices installed and available. -Then, users can request devices in a -[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) -specification as they request other types of resources, with the following limitations: - +Then, users can request devices as part of a Pod specification +(see [`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)). +Requesting extended resources is similar to how you manage requests and limits for +other resources, with the following differences: * Extended resources are only supported as integer resources and cannot be overcommitted. -* Devices cannot be shared among Containers. +* Devices cannot be shared between containers. + +### Example {#example-pod} Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo` on certain nodes. Here is an example of a pod requesting this resource to run a demo workload: @@ -174,7 +175,7 @@ a Kubernetes release with a newer device plugin API version, upgrade your device to support both versions before upgrading these nodes. Taking that approach will ensure the continuous functioning of the device allocations during the upgrade. -## Monitoring Device Plugin Resources +## Monitoring device plugin resources {{< feature-state for_k8s_version="v1.15" state="beta" >}} @@ -310,7 +311,7 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20. -## Device Plugin integration with the Topology Manager +## Device plugin integration with the Topology Manager {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -319,7 +320,7 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin ```gRPC message TopologyInfo { - repeated NUMANode nodes = 1; + repeated NUMANode nodes = 1; } message NUMANode { @@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. ## Device plugin examples {#examples} +{{% thirdparty-content %}} + Here are some examples of device plugin implementations: * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) @@ -357,5 +360,5 @@ Here are some examples of device plugin implementations: * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node -* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) +* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index 3053544cd2..210d33dcd4 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -42,9 +42,10 @@ on every resource object. | `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string | | `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string | -To illustrate these labels in action, consider the following StatefulSet object: +To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object: ```yaml +# This is an excerpt apiVersion: apps/v1 kind: StatefulSet metadata: diff --git a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md index fff925b6c5..63776520a9 100644 --- a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -106,7 +106,7 @@ description: "This priority class should be used for XYZ service pods only." {{< feature-state for_k8s_version="v1.19" state="beta" >}} -Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue +Pods with `preemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue, @@ -122,16 +122,16 @@ allowing other pods with lower priority to be scheduled before them. Non-preempting pods may still be preempted by other, high-priority pods. -`PreemptionPolicy` defaults to `PreemptLowerPriority`, +`preemptionPolicy` defaults to `PreemptLowerPriority`, which will allow pods of that PriorityClass to preempt lower-priority pods (as is existing default behavior). -If `PreemptionPolicy` is set to `Never`, +If `preemptionPolicy` is set to `Never`, pods in that PriorityClass will be non-preempting. An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. -The high priority job with `PreemptionPolicy: Never` will be scheduled +The high priority job with `preemptionPolicy: Never` will be scheduled ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free. diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index f51e10e558..cd9124b6a7 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -434,7 +434,7 @@ provisioner: example.com/external-nfs parameters: server: nfs-server.example.com path: /share - readOnly: false + readOnly: "false" ``` * `server`: Server is the hostname or IP address of the NFS server. @@ -797,7 +797,7 @@ parameters: storagePool: sp1 storageMode: ThinProvisioned secretRef: sio-secret - readOnly: false + readOnly: "false" fsType: xfs ``` diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index d2284d9dbb..8ff46d4f50 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -615,7 +615,7 @@ spec: ``` The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting -`manualSelector: true` tells the system to that you know what you are doing and to allow this +`manualSelector: true` tells the system that you know what you are doing and to allow this mismatch. ### Job tracking with finalizers diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 9656a816e7..07cf3c77a6 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -229,7 +229,7 @@ when both the following statements apply: * All conditions specified in `readinessGates` are `True`. When a Pod's containers are Ready but at least one custom condition is missing or -`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`. +`False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`. ## Container probes diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 592b59ded9..bd11ae6cb5 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -249,6 +249,7 @@ Home | [All heading and subheading URLs](/docs/home/) Setup | [All heading and subheading URLs](/docs/setup/) Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file +Releases | [All heading and subheading URLs](/releases) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md index e59ffe4fe3..c577c3f8be 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -147,7 +147,7 @@ separately for reviewer status in SIG Docs. To apply: 1. Open a pull request that adds your GitHub user name to a section of the - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) file + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file in the `kubernetes/website` repository. {{< note >}} @@ -219,7 +219,7 @@ separately for approver status in SIG Docs. To apply: 1. Open a pull request adding yourself to a section of the - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file in the `kubernetes/website` repository. {{< note >}} diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 6eb9e1d40e..f9d2336f07 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -53,7 +53,7 @@ different Kubernetes components. |---------|---------|-------|-------|-------| | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | -| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 | +| `APIPriorityAndFairness` | `false` | Alpha | 1.18 | 1.19 | | `APIPriorityAndFairness` | `true` | Beta | 1.20 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 | | `APIResponseCompression` | `true` | Beta | 1.16 | | @@ -167,8 +167,8 @@ different Kubernetes components. | `NodeSwap` | `false` | Alpha | 1.22 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | Beta | 1.19 | | -| `OpenAPIEnum` | `false` | Alpha | 1.23 | | -| `OpenAPIv3` | `false` | Alpha | 1.23 | | +| `OpenAPIEnums` | `false` | Alpha | 1.23 | | +| `OpenAPIV3` | `false` | Alpha | 1.23 | | | `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | | | `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | 1.21 | | `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | | @@ -784,7 +784,8 @@ Each feature gate is designed for enabling/disabling a specific feature: [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). - `ExpandCSIVolumes`: Enable the expanding of CSI volumes. - `ExpandedDNSConfig`: Enable kubelet and kube-apiserver to allow more DNS - search paths and longer list of DNS search paths. See + search paths and longer list of DNS search paths. This feature requires container + runtime support(Containerd: v1.5.6 or higher, CRI-O: v1.22 or higher). See [Expanded DNS Configuration](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration). - `ExpandInUsePersistentVolumes`: Enable expanding in-use PVCs. See [Resizing an in-use PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim). @@ -913,9 +914,9 @@ Each feature gate is designed for enabling/disabling a specific feature: Must be used with `KubeletConfiguration.failSwapOn` set to false. For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory) - `NonPreemptingPriority`: Enable `preemptionPolicy` field for PriorityClass and Pod. -- `OpenAPIEnum`: Enables populating "enum" fields of OpenAPI schemas in the +- `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the spec returned from the API server. -- `OpenAPIv3`: Enables the API server to publish OpenAPI v3. +- `OpenAPIV3`: Enables the API server to publish OpenAPI v3. - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from being deleted when it is still used by any Pod. - `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) diff --git a/content/en/docs/reference/glossary/container-runtime-interface.md b/content/en/docs/reference/glossary/container-runtime-interface.md index 11f7bc50f4..28a67cbbb4 100644 --- a/content/en/docs/reference/glossary/container-runtime-interface.md +++ b/content/en/docs/reference/glossary/container-runtime-interface.md @@ -19,4 +19,4 @@ The Kubernetes Container Runtime Interface (CRI) defines the main [gRPC](https://grpc.io) protocol for the communication between the [cluster components](/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and -{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index b5756e5cc2..5693274a59 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -41,8 +41,6 @@ For control-plane nodes additional steps are performed: 1. Adding new local etcd member. -1. Adding this node to the ClusterStatus of the kubeadm cluster. - ### Using join phases with kubeadm {#join-phases} Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`. diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index 93d5ce0cbb..9a5f9b29fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -16,8 +16,7 @@ Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join `kubeadm reset` is responsible for cleaning up a node local file system from files that were created using the `kubeadm init` or `kubeadm join` commands. For control-plane nodes `reset` also removes the local stacked -etcd member of this node from the etcd cluster and also removes this node's information from the kubeadm -`ClusterStatus` object. `ClusterStatus` is a kubeadm managed Kubernetes API object that holds a list of kube-apiserver endpoints. +etcd member of this node from the etcd cluster. `kubeadm reset phase` can be used to execute the separate phases of the above workflow. To skip a list of phases you can use the `--skip-phases` flag, which works in a similar way to diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 0319ee17fc..b14cd79613 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -16,19 +16,20 @@ or upgrades for such nodes. The long term plan is to empower the tool aspects. {{< /note >}} -Kubeadm defaults to running a single member etcd cluster in a static pod managed -by the kubelet on the control plane node. This is not a high availability setup -as the etcd cluster contains only one member and cannot sustain any members -becoming unavailable. This task walks through the process of creating a high -availability etcd cluster of three members that can be used as an external etcd -when using kubeadm to set up a kubernetes cluster. +By default, kubeadm runs a local etcd instance on each control plane node. +It is also possible to treat the etcd cluster as external and provision +etcd instances on separate hosts. The differences between the two approaches are covered in the +[Options for Highly Available topology][/docs/setup/production-environment/tools/kubeadm/ha-topology] page. +This task walks through the process of creating a high availability external +etcd cluster of three members that can be used by kubeadm during cluster creation. ## {{% heading "prerequisites" %}} -* Three hosts that can talk to each other over ports 2379 and 2380. This +* Three hosts that can talk to each other over TCP ports 2379 and 2380. This document assumes these default ports. However, they are configurable through the kubeadm config file. -* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +* Each host must have systemd and a bash compatible shell installed. +* Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). * Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet. @@ -48,6 +49,11 @@ the certificates described below; no other cryptographic tooling is required for this example. {{< /note >}} +{{< note >}} +The examples below use IPv4 addresses but you can also configure kubeadm, the kubelet and etcd +to use IPv6 addresses. Dual-stack is supported by some Kubernetes options, but not by etcd. For more details +on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/). +{{< /note >}} 1. Configure the kubelet to be a service manager for etcd. @@ -59,8 +65,9 @@ this example. cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf [Service] ExecStart= - # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". - ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd + # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". + # Replace the value of "--container-runtime-endpoint" for a different container runtime if needed. + ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock Restart=always EOF @@ -80,21 +87,34 @@ this example. member running on it using the following script. ```sh - # Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts + # Update HOST0, HOST1 and HOST2 with the IPs of your hosts export HOST0=10.0.0.6 export HOST1=10.0.0.7 export HOST2=10.0.0.8 + # Update NAME0, NAME1 and NAME2 with the hostnames of your hosts + export NAME0="infra0" + export NAME1="infra1" + export NAME2="infra2" + # Create temp directories to store files that will end up on other hosts. mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/ - ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2}) - NAMES=("infra0" "infra1" "infra2") + HOSTS=(${HOST0} ${HOST1} ${HOST2}) + NAMES=(${NAME0} ${NAME1} ${NAME2}) - for i in "${!ETCDHOSTS[@]}"; do - HOST=${ETCDHOSTS[$i]} + for i in "${!HOSTS[@]}"; do + HOST=${HOSTS[$i]} NAME=${NAMES[$i]} cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml + --- + apiVersion: "kubeadm.k8s.io/v1beta3" + kind: InitConfiguration + nodeRegistration: + name: ${NAME} + localAPIEndpoint: + advertiseAddress: ${HOST} + --- apiVersion: "kubeadm.k8s.io/v1beta3" kind: ClusterConfiguration etcd: @@ -104,7 +124,7 @@ this example. peerCertSANs: - "${HOST}" extraArgs: - initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380 + initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 initial-cluster-state: new name: ${NAME} listen-peer-urls: https://${HOST}:2380 diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 153243ffef..aa7a623c42 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -37,8 +37,11 @@ The upgrade workflow at high level is the following: ### Additional information -- [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version - upgrades is required. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads. +- The instructions below outline when to drain each node during the upgrade process. +If you are performing a **minor** version upgrade for any kubelet, you **must** +first drain the node (or nodes) that you are upgrading. In the case of control plane nodes, +they could be running CoreDNS Pods or other critical workloads. For more information see +[Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/). - All containers are restarted after upgrade, because the container spec hash value is changed. diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index ddfefb6f49..da3bdc1148 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -52,7 +52,7 @@ For example: on COS images, Docker exposes its Unix domain socket at Here's a sample shell script to find Pods that have a mount directly mapping the Docker socket. This script outputs the namespace and name of the pod. You can -remove the grep `/var/run/docker.sock` to review other mounts. +remove the `grep '/var/run/docker.sock'` to review other mounts. ```bash kubectl get pods --all-namespaces \ diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index 949f1922c4..0024ff8bbc 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -26,19 +26,18 @@ Reload your shell and verify that bash-completion is correctly installed by typi ### Enable kubectl autocompletion +#### Bash + You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this: -- Source the completion script in your `~/.bashrc` file: - - ```bash - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` - -- Add the completion script to the `/etc/bash_completion.d` directory: - - ```bash - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` +{{< tabs name="kubectl_bash_autocompletion" >}} +{{{< tab name="User" codelang="bash" >}} +echo 'source <(kubectl completion bash)' >>~/.bashrc +{{< /tab >}} +{{< tab name="System" codelang="bash" >}} +kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null +{{< /tab >}}} +{{< /tabs >}} If you have an alias for kubectl, you can extend shell completion to work with that alias: diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 0f1181e2cf..01bb9a6552 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -47,12 +47,6 @@ Before walking through each tutorial, you may want to bookmark the * [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) -## Clusters - -* [AppArmor](/docs/tutorials/clusters/apparmor/) - -* [seccomp](/docs/tutorials/clusters/seccomp/) - ## Services * [Using Source IP](/docs/tutorials/services/source-ip/) @@ -61,7 +55,8 @@ Before walking through each tutorial, you may want to bookmark the * [Apply Pod Security Standards at Cluster level](/docs/tutorials/security/cluster-level-pss/) * [Apply Pod Security Standards at Namespace level](/docs/tutorials/security/ns-level-pss/) - +* [AppArmor](/docs/tutorials/security/apparmor/) +* [seccomp](/docs/tutorials/security/seccomp/) ## {{% heading "whatsnext" %}} If you would like to write a tutorial, see diff --git a/content/en/docs/tutorials/clusters/_index.md b/content/en/docs/tutorials/clusters/_index.md deleted file mode 100644 index 2db6156b6f..0000000000 --- a/content/en/docs/tutorials/clusters/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Clusters" -weight: 60 ---- - diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/security/apparmor.md similarity index 100% rename from content/en/docs/tutorials/clusters/apparmor.md rename to content/en/docs/tutorials/security/apparmor.md diff --git a/content/en/docs/tutorials/clusters/seccomp.md b/content/en/docs/tutorials/security/seccomp.md similarity index 100% rename from content/en/docs/tutorials/clusters/seccomp.md rename to content/en/docs/tutorials/security/seccomp.md diff --git a/content/fr/_index.html b/content/fr/_index.html index 836e5b7504..0b7db944f9 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -43,12 +43,12 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in

- Venez au KubeCon NA Los Angeles, USA du 11 au 15 Octobre 2021 + Venez au KubeCon Detroit, Michigan, USA du 24 au 28 Octobre 2022



- Venez au KubeCon EU Valence, Espagne du 15 au 20 Mai 2022 + Venez au KubeCon EU Valence, Espagne + Virtuel du 16 au 20 Mai 2022
@@ -58,4 +58,4 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 2ab0b3ae5a..94bd0744f5 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -527,5 +527,5 @@ Pour plus d'informations sur Minikube, voir la [proposition](https://git.k8s.io/ Les contributions, questions et commentaires sont les bienvenus et sont encouragés ! Les développeurs de minikube sont dans le canal #minikube du [Slack](https://kubernetes.slack.com) de Kubernetes (recevoir une invitation [ici](http://slack.kubernetes.io/)). -Nous avons également la liste de diffusion [kubernetes-dev Google Groupes](https://groups.google.com/forum/#!forum/kubernetes-dev). +Nous avons également la liste de diffusion [dev@kubernetes Google Groupes](https://groups.google.com/a/kubernetes.io/g/dev/). Si vous publiez sur la liste, veuillez préfixer votre sujet avec "minikube:". diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 393829cf2e..4d748e7cef 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -263,12 +263,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also -complicated way to build an overlay network. This is endorsed by several of the -"Big Shops" for networking. - ### OVN (Open Virtual Networking) OVN is an opensource network virtualization solution developed by the diff --git a/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md new file mode 100644 index 0000000000..77b354dc70 --- /dev/null +++ b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -0,0 +1,1187 @@ +--- +title: kube-apiserver +content_type: tool-reference +weight: 30 +auto_generated: true +--- + + + + + +## {{% heading "synopsis" %}} + + +The Kubernetes API server validates and configures data +for the api objects which include pods, services, replicationcontrollers, and +others. The API Server services REST operations and provides the frontend to the +cluster's shared state through which all other components interact. + +``` +kube-apiserver [flags] +``` + +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header

If true, adds the file directory to the header of the log messages

--admission-control-config-file string

File with admission control configuration.

--advertise-address string

The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used.

--allow-metric-labels stringToString     Default: []

The map from metric-label to value allow-list of this label. The key's format is <MetricName>,<LabelName>. The value's format is <allowed_value>,<allowed_value>...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-privileged

If true, allow privileged containers. [default=false]

--alsologtostderr

log to standard error as well as files

--anonymous-auth     Default: true

Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated.

--api-audiences strings

Identifiers of the API. The service account token authenticator will validate that tokens used against the API are bound to at least one of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL.

--apiserver-count int     Default: 1

The number of apiservers running in the cluster, must be a positive number. (In use when --endpoint-reconciler-type=master-count is enabled.)

--audit-log-batch-buffer-size int     Default: 10000

The size of the buffer to store events before batching and writing. Only used in batch mode.

--audit-log-batch-max-size int     Default: 1

The maximum size of a batch. Only used in batch mode.

--audit-log-batch-max-wait duration

The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.

--audit-log-batch-throttle-burst int

Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.

--audit-log-batch-throttle-enable

Whether batching throttling is enabled. Only used in batch mode.

--audit-log-batch-throttle-qps float

Maximum average number of batches per second. Only used in batch mode.

--audit-log-compress

If set, the rotated log files will be compressed using gzip.

--audit-log-format string     Default: "json"

Format of saved audits. "legacy" indicates 1-line text format for each event. "json" indicates structured json format. Known formats are legacy,json.

--audit-log-maxage int

The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.

--audit-log-maxbackup int

The maximum number of old audit log files to retain.

--audit-log-maxsize int

The maximum size in megabytes of the audit log file before it gets rotated.

--audit-log-mode string     Default: "blocking"

Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict.

--audit-log-path string

If set, all requests coming to the apiserver will be logged to this file. '-' means standard out.

--audit-log-truncate-enabled

Whether event and batch truncating is enabled.

--audit-log-truncate-max-batch-size int     Default: 10485760

Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size.

--audit-log-truncate-max-event-size int     Default: 102400

Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded.

--audit-log-version string     Default: "audit.k8s.io/v1"

API group and version used for serializing audit events written to log.

--audit-policy-file string

Path to the file that defines the audit policy configuration.

--audit-webhook-batch-buffer-size int     Default: 10000

The size of the buffer to store events before batching and writing. Only used in batch mode.

--audit-webhook-batch-max-size int     Default: 400

The maximum size of a batch. Only used in batch mode.

--audit-webhook-batch-max-wait duration     Default: 30s

The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.

--audit-webhook-batch-throttle-burst int     Default: 15

Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.

--audit-webhook-batch-throttle-enable     Default: true

Whether batching throttling is enabled. Only used in batch mode.

--audit-webhook-batch-throttle-qps float     Default: 10

Maximum average number of batches per second. Only used in batch mode.

--audit-webhook-config-file string

Path to a kubeconfig formatted file that defines the audit webhook configuration.

--audit-webhook-initial-backoff duration     Default: 10s

The amount of time to wait before retrying the first failed request.

--audit-webhook-mode string     Default: "batch"

Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict.

--audit-webhook-truncate-enabled

Whether event and batch truncating is enabled.

--audit-webhook-truncate-max-batch-size int     Default: 10485760

Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size.

--audit-webhook-truncate-max-event-size int     Default: 102400

Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded.

--audit-webhook-version string     Default: "audit.k8s.io/v1"

API group and version used for serializing audit events written to webhook.

--authentication-token-webhook-cache-ttl duration     Default: 2m0s

The duration to cache responses from the webhook token authenticator.

--authentication-token-webhook-config-file string

File with webhook configuration for token authentication in kubeconfig format. The API server will query the remote service to determine authentication for bearer tokens.

--authentication-token-webhook-version string     Default: "v1beta1"

The API version of the authentication.k8s.io TokenReview to send to and expect from the webhook.

--authorization-mode strings     Default: "AlwaysAllow"

Ordered list of plug-ins to do authorization on secure port. Comma-delimited list of: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.

--authorization-policy-file string

File with authorization policy in json line by line format, used with --authorization-mode=ABAC, on the secure port.

--authorization-webhook-cache-authorized-ttl duration     Default: 5m0s

The duration to cache 'authorized' responses from the webhook authorizer.

--authorization-webhook-cache-unauthorized-ttl duration     Default: 30s

The duration to cache 'unauthorized' responses from the webhook authorizer.

--authorization-webhook-config-file string

File with webhook configuration in kubeconfig format, used with --authorization-mode=Webhook. The API server will query the remote service to determine access on the API server's secure port.

--authorization-webhook-version string     Default: "v1beta1"

The API version of the authorization.k8s.io SubjectAccessReview to send to and expect from the webhook.

--azure-container-registry-config string

Path to the file containing Azure container registry configuration information.

--bind-address string     Default: 0.0.0.0

The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.

--cert-dir string     Default: "/var/run/kubernetes"

The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.

--client-ca-file string

If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.

--cloud-config string

The path to the cloud provider configuration file. Empty string for no configuration file.

--cloud-provider string

The provider for cloud services. Empty string for no provider.

--cloud-provider-gce-l7lb-src-cidrs cidrs     Default: 130.211.0.0/22,35.191.0.0/16

CIDRs opened in GCE firewall for L7 LB traffic proxy & health checks

--contention-profiling

Enable lock contention profiling, if profiling is enabled

--cors-allowed-origins strings

List of allowed origins for CORS, comma separated. An allowed origin can be a regular expression to support subdomain matching. If this list is empty CORS will not be enabled.

--default-not-ready-toleration-seconds int     Default: 300

Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.

--default-unreachable-toleration-seconds int     Default: 300

Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.

--default-watch-cache-size int     Default: 100

Default watch cache size. If zero, watch cache will be disabled for resources that do not have a default watch size set.

--delete-collection-workers int     Default: 1

Number of workers spawned for DeleteCollection call. These are used to speed up namespace cleanup.

--disable-admission-plugins strings

admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

--disabled-metrics strings

This flag provides an escape hatch for misbehaving metrics. You must provide the fully qualified metric name in order to disable it. Disclaimer: disabling metrics is higher in precedence than showing hidden metrics.

--egress-selector-config-file string

File with apiserver egress selector configuration.

--enable-admission-plugins strings

admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

--enable-aggregator-routing

Turns on aggregator routing requests to endpoints IP rather than cluster IP.

--enable-bootstrap-token-auth

Enable to allow secrets of type 'bootstrap.kubernetes.io/token' in the 'kube-system' namespace to be used for TLS bootstrapping authentication.

--enable-garbage-collector     Default: true

Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-controller-manager.

--enable-priority-and-fairness     Default: true

If true and the APIPriorityAndFairness feature gate is enabled, replace the max-in-flight handler with an enhanced one that queues and dispatches with priority and fairness

--encryption-provider-config string

The file containing configuration for encryption providers to be used for storing secrets in etcd

--endpoint-reconciler-type string     Default: "lease"

Use an endpoint reconciler (master-count, lease, none)

--etcd-cafile string

SSL Certificate Authority file used to secure etcd communication.

--etcd-certfile string

SSL certification file used to secure etcd communication.

--etcd-compaction-interval duration     Default: 5m0s

The interval of compaction requests. If 0, the compaction request from apiserver is disabled.

--etcd-count-metric-poll-period duration     Default: 1m0s

Frequency of polling etcd for number of resources per type. 0 disables the metric collection.

--etcd-db-metric-poll-interval duration     Default: 30s

The interval of requests to poll etcd and update metric. 0 disables the metric collection

--etcd-healthcheck-timeout duration     Default: 2s

The timeout to use when checking etcd health.

--etcd-keyfile string

SSL key file used to secure etcd communication.

--etcd-prefix string     Default: "/registry"

The prefix to prepend to all resource paths in etcd.

--etcd-servers strings

List of etcd servers to connect with (scheme://ip:port), comma separated.

--etcd-servers-overrides strings

Per-resource etcd servers overrides, comma separated. The individual override format: group/resource#servers, where servers are URLs, semicolon separated. Note that this applies only to resources compiled into this server binary.

--event-ttl duration     Default: 1h0m0s

Amount of time to retain events.

--experimental-logging-sanitization

[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens).
Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.

--external-hostname string

The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs or OpenID Discovery).

--feature-gates <comma-separated 'key=True|False' pairs>

A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (ALPHA - default=false)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
CSIMigrationAzureDisk=true|false (BETA - default=false)
CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
CSIVolumeHealth=true|false (ALPHA - default=false)
CSRDuration=true|false (BETA - default=true)
ConfigurableFSGroupPolicy=true|false (BETA - default=true)
ControllerManagerLeaderMigration=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DefaultPodTopologySpread=true|false (BETA - default=true)
DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=false)
EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GenericEphemeralVolume=true|false (BETA - default=true)
GracefulNodeShutdown=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
IPv6DualStack=true|false (BETA - default=true)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
IndexedJob=true|false (BETA - default=true)
IngressClassNamespacedParams=true|false (BETA - default=true)
JobTrackingWithFinalizers=true|false (ALPHA - default=false)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
NetworkPolicyEndPort=true|false (BETA - default=true)
NodeSwap=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
PodAffinityNamespaceSelector=true|false (BETA - default=true)
PodDeletionCost=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
PodSecurity=true|false (ALPHA - default=false)
PreferNominatedNode=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
ServiceLBNodePortControl=true|false (BETA - default=true)
ServiceLoadBalancerClass=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
SuspendJob=true|false (BETA - default=true)
TTLAfterFinished=true|false (BETA - default=true)
TopologyAwareHints=true|false (ALPHA - default=false)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (ALPHA - default=false)

--goaway-chance float

To prevent HTTP/2 clients from getting stuck on a single apiserver, randomly close a connection (GOAWAY). The client's other in-flight requests won't be affected, and the client will reconnect, likely landing on a different apiserver after going through the load balancer again. This argument sets the fraction of requests that will be sent a GOAWAY. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. Min is 0 (off), Max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.

-h, --help

help for kube-apiserver

--http2-max-streams-per-connection int

The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.

--identity-lease-duration-seconds int     Default: 3600

The duration of kube-apiserver lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.)

--identity-lease-renew-interval-seconds int     Default: 10

The interval of kube-apiserver renewing its lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.)

--kubelet-certificate-authority string

Path to a cert file for the certificate authority.

--kubelet-client-certificate string

Path to a client cert file for TLS.

--kubelet-client-key string

Path to a client key file for TLS.

--kubelet-preferred-address-types strings     Default: "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"

List of the preferred NodeAddressTypes to use for kubelet connections.

--kubelet-timeout duration     Default: 5s

Timeout for kubelet operations.

--kubernetes-service-node-port int

If non-zero, the Kubernetes master service (which apiserver creates/maintains) will be of type NodePort, using this as the value of the port. If zero, the Kubernetes master service will be of type ClusterIP.

--lease-reuse-duration-seconds int     Default: 60

The time in seconds that each lease is reused. A lower value could avoid large number of objects reusing the same lease. Notice that a too small value may cause performance problems at storage layer.

--livez-grace-period duration

This option represents the maximum amount of time it should take for apiserver to complete its startup sequence and become live. From apiserver's start time to when this amount of time has elapsed, /livez will assume that unfinished post-start hooks will complete successfully and therefore return true.

--log-backtrace-at <a string in the form 'file:N'>     Default: :0

when logging hits line file:N, emit a stack trace

--log-dir string

If non-empty, write log files in this directory

--log-file string

If non-empty, use this log file

--log-file-max-size uint     Default: 1800

Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.

--log-flush-frequency duration     Default: 5s

Maximum number of seconds between log flushes

--logging-format string     Default: "text"

Sets the log format. Permitted formats: "text".
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --one-output, --skip-headers, --skip-log-headers, --stderrthreshold, --vmodule, --log-flush-frequency.
Non-default choices are currently alpha and subject to change without warning.

--logtostderr     Default: true

log to standard error instead of files

--master-service-namespace string     Default: "default"

DEPRECATED: the namespace from which the Kubernetes master services should be injected into pods.

--max-connection-bytes-per-sec int

If non-zero, throttle each user connection to this number of bytes/sec. Currently only applies to long-running requests.

--max-mutating-requests-inflight int     Default: 200

This and --max-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of mutating requests in flight, or a zero value disables the limit completely.

--max-requests-inflight int     Default: 400

This and --max-mutating-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of non-mutating requests in flight, or a zero value disables the limit completely.

--min-request-timeout int     Default: 1800

An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load.

--oidc-ca-file string

If set, the OpenID server's certificate will be verified by one of the authorities in the oidc-ca-file, otherwise the host's root CA set will be used.

--oidc-client-id string

The client ID for the OpenID Connect client, must be set if oidc-issuer-url is set.

--oidc-groups-claim string

If provided, the name of a custom OpenID Connect claim for specifying user groups. The claim value is expected to be a string or array of strings. This flag is experimental, please see the authentication documentation for further details.

--oidc-groups-prefix string

If provided, all groups will be prefixed with this value to prevent conflicts with other authentication strategies.

--oidc-issuer-url string

The URL of the OpenID issuer, only HTTPS scheme will be accepted. If set, it will be used to verify the OIDC JSON Web Token (JWT).

--oidc-required-claim <comma-separated 'key=value' pairs>

A key=value pair that describes a required claim in the ID Token. If set, the claim is verified to be present in the ID Token with a matching value. Repeat this flag to specify multiple claims.

--oidc-signing-algs strings     Default: "RS256"

Comma-separated list of allowed JOSE asymmetric signing algorithms. JWTs with a 'alg' header value not in this list will be rejected. Values are defined by RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.

--oidc-username-claim string     Default: "sub"

The OpenID claim to use as the user name. Note that claims other than the default ('sub') is not guaranteed to be unique and immutable. This flag is experimental, please see the authentication documentation for further details.

--oidc-username-prefix string

If provided, all usernames will be prefixed with this value. If not provided, username claims other than 'email' are prefixed by the issuer URL to avoid clashes. To skip any prefixing, provide the value '-'.

--one-output

If true, only write logs to their native severity level (vs also writing to each lower severity level)

--permit-address-sharing

If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like 0.0.0.0 and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false]

--permit-port-sharing

If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false]

--profiling     Default: true

Enable profiling via web interface host:port/debug/pprof/

--proxy-client-cert-file string

Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components receiving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.

--proxy-client-key-file string

Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.

--request-timeout duration     Default: 1m0s

An optional field indicating the duration a handler must keep a request open before timing it out. This is the default request timeout for requests but may be overridden by flags such as --min-request-timeout for specific types of requests.

--requestheader-allowed-names strings

List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.

--requestheader-client-ca-file string

Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.

--requestheader-extra-headers-prefix strings

List of request header prefixes to inspect. X-Remote-Extra- is suggested.

--requestheader-group-headers strings

List of request headers to inspect for groups. X-Remote-Group is suggested.

--requestheader-username-headers strings

List of request headers to inspect for usernames. X-Remote-User is common.

--runtime-config <comma-separated 'key=value' pairs>

A set of key=value pairs that enable or disable built-in APIs. Supported options are:
v1=true|false for the core API group
<group>/<version>=true|false for a specific API group and version (e.g. apps/v1=true)
api/all=true|false controls all API versions
api/ga=true|false controls all API versions of the form v[0-9]+
api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+
api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+
api/legacy is deprecated, and will be removed in a future version

--secure-port int     Default: 6443

The port on which to serve HTTPS with authentication and authorization. It cannot be switched off with 0.

--service-account-extend-token-expiration     Default: true

Turns on projected service account expiration extension during token generation, which helps safe transition from legacy token to bound service account token feature. If this flag is enabled, admission injected tokens would be extended up to 1 year to prevent unexpected failure during transition, ignoring value of service-account-max-token-expiration.

--service-account-issuer strings

Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted.

--service-account-jwks-uri string

Overrides the URI for the JSON Web Key Set in the discovery doc served at /.well-known/openid-configuration. This flag is useful if the discovery docand key set are served to relying parties from a URL other than the API server's external (as auto-detected or overridden with external-hostname). Only valid if the ServiceAccountIssuerDiscovery feature gate is enabled.

--service-account-key-file strings

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided

--service-account-lookup     Default: true

If true, validate ServiceAccount tokens exist in etcd as part of authentication.

--service-account-max-token-expiration duration

The maximum validity duration of a token created by the service account token issuer. If an otherwise valid TokenRequest with a validity duration larger than this value is requested, a token will be issued with a validity duration of this value.

--service-account-signing-key-file string

Path to the file that contains the current private key of the service account token issuer. The issuer will sign issued ID tokens with this private key.

--service-cluster-ip-range string

A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes or pods. Max of two dual-stack CIDRs is allowed.

--service-node-port-range <a string in the form 'N1-N2'>     Default: 30000-32767

A port range to reserve for services with NodePort visibility. Example: '30000-32767'. Inclusive at both ends of the range.

--show-hidden-metrics-for-version string

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

--shutdown-delay-duration duration

Time to delay the termination. During that time the server keeps serving requests normally. The endpoints /healthz and /livez will return success, but /readyz immediately returns failure. Graceful termination starts after this delay has elapsed. This can be used to allow load balancer to stop sending traffic to this server.

--skip-headers

If true, avoid header prefixes in the log messages

--skip-log-headers

If true, avoid headers when opening log files

--stderrthreshold int     Default: 2

logs at or above this threshold go to stderr

--storage-backend string

The storage backend for persistence. Options: 'etcd3' (default).

--storage-media-type string     Default: "application/vnd.kubernetes.protobuf"

The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting.

--strict-transport-security-directives strings

List of directives for HSTS, comma separated. If this list is empty, then HSTS directives will not be added. Example: 'max-age=31536000,includeSubDomains,preload'

--tls-cert-file string

File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.

--tls-cipher-suites strings

Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

File containing the default x509 private key matching --tls-cert-file.

--tls-sni-cert-key string

A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".

--token-auth-file string

If set, the file that will be used to secure the secure port of the API server via token authentication.

--tracing-config-file string

File with apiserver tracing configuration.

-v, --v int

number for the log level verbosity

--version version[=true]

Print version information and quit

--vmodule <comma-separated 'pattern=N' settings>

comma-separated list of pattern=N settings for file-filtered logging

--watch-cache     Default: true

Enable watch caching in the apiserver

--watch-cache-sizes strings

Watch cache size settings for some resources (pods, nodes, etc.), comma separated. The individual setting format: resource[.group]#size, where resource is lowercase plural (no version), group is omitted for resources of apiVersion v1 (the legacy core API) and included for others, and size is a number. It takes effect when watch-cache is enabled. Some resources (replicationcontrollers, endpoints, nodes, pods, services, apiservices.apiregistration.k8s.io) have system defaults set by heuristics, others default to default-watch-cache-size

+ + + diff --git a/content/ja/docs/reference/config-api/apiserver-audit.v1.md b/content/ja/docs/reference/config-api/apiserver-audit.v1.md new file mode 100644 index 0000000000..11df06bd8c --- /dev/null +++ b/content/ja/docs/reference/config-api/apiserver-audit.v1.md @@ -0,0 +1,620 @@ +--- +title: kube-apiserver Audit Configuration (v1) +content_type: tool-reference +package: audit.k8s.io/v1 +auto_generated: true +--- + + +## Resource Types + + +- [Event](#audit-k8s-io-v1-Event) +- [EventList](#audit-k8s-io-v1-EventList) +- [Policy](#audit-k8s-io-v1-Policy) +- [PolicyList](#audit-k8s-io-v1-PolicyList) + + + + +## `Event` {#audit-k8s-io-v1-Event} + + + + +**Appears in:** + +- [EventList](#audit-k8s-io-v1-EventList) + + +Event captures all the information that can be included in an API audit log. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string
audit.k8s.io/v1
kind
string
Event
level [Required]
+Level +
+ AuditLevel at which event was generated
auditID [Required]
+k8s.io/apimachinery/pkg/types.UID +
+ Unique audit ID, generated for each request.
stage [Required]
+Stage +
+ Stage of the request handling when this event instance was generated.
requestURI [Required]
+string +
+ RequestURI is the request URI as sent by the client to a server.
verb [Required]
+string +
+ Verb is the kubernetes verb associated with the request. +For non-resource requests, this is the lower-cased HTTP method.
user [Required]
+authentication/v1.UserInfo +
+ Authenticated user information.
impersonatedUser
+authentication/v1.UserInfo +
+ Impersonated user information.
sourceIPs
+[]string +
+ Source IPs, from where the request originated and intermediate proxies.
userAgent
+string +
+ UserAgent records the user agent string reported by the client. +Note that the UserAgent is provided by the client, and must not be trusted.
objectRef
+ObjectReference +
+ Object reference this request is targeted at. +Does not apply for List-type requests, or non-resource requests.
responseStatus
+meta/v1.Status +
+ The response status, populated even when the ResponseObject is not a Status type. +For successful responses, this will only include the Code and StatusSuccess. +For non-status type error responses, this will be auto-populated with the error Message.
requestObject
+k8s.io/apimachinery/pkg/runtime.Unknown +
+ API object from the request, in JSON format. The RequestObject is recorded as-is in the request +(possibly re-encoded as JSON), prior to version conversion, defaulting, admission or +merging. It is an external versioned object type, and may not be a valid object on its own. +Omitted for non-resource requests. Only logged at Request Level and higher.
responseObject
+k8s.io/apimachinery/pkg/runtime.Unknown +
+ API object returned in the response, in JSON. The ResponseObject is recorded after conversion +to the external type, and serialized as JSON. Omitted for non-resource requests. Only logged +at Response Level.
requestReceivedTimestamp
+meta/v1.MicroTime +
+ Time the request reached the apiserver.
stageTimestamp
+meta/v1.MicroTime +
+ Time the request reached current audit stage.
annotations
+map[string]string +
+ Annotations is an unstructured key value map stored with an audit event that may be set by +plugins invoked in the request serving chain, including authentication, authorization and +admission plugins. Note that these annotations are for the audit event, and do not correspond +to the metadata.annotations of the submitted object. Keys should uniquely identify the informing +component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values +should be short. Annotations are included in the Metadata level.
+ + + +## `EventList` {#audit-k8s-io-v1-EventList} + + + + + +EventList is a list of audit Events. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string
audit.k8s.io/v1
kind
string
EventList
metadata
+meta/v1.ListMeta +
+ No description provided. +
items [Required]
+[]Event +
+ No description provided. +
+ + + +## `Policy` {#audit-k8s-io-v1-Policy} + + + + +**Appears in:** + +- [PolicyList](#audit-k8s-io-v1-PolicyList) + + +Policy defines the configuration of audit logging, and the rules for how different request +categories are logged. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string
audit.k8s.io/v1
kind
string
Policy
metadata
+meta/v1.ObjectMeta +
+ ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field.
rules [Required]
+[]PolicyRule +
+ Rules specify the audit Level a request should be recorded at. +A request may match multiple rules, in which case the FIRST matching rule is used. +The default audit level is None, but can be overridden by a catch-all rule at the end of the list. +PolicyRules are strictly ordered.
omitStages
+[]Stage +
+ OmitStages is a list of stages for which no events are created. Note that this can also +be specified per rule in which case the union of both are omitted.
+ + + +## `PolicyList` {#audit-k8s-io-v1-PolicyList} + + + + + +PolicyList is a list of audit Policies. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string
audit.k8s.io/v1
kind
string
PolicyList
metadata
+meta/v1.ListMeta +
+ No description provided. +
items [Required]
+[]Policy +
+ No description provided. +
+ + + +## `GroupResources` {#audit-k8s-io-v1-GroupResources} + + + + +**Appears in:** + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +GroupResources represents resource kinds in an API group. + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
group
+string +
+ Group is the name of the API group that contains the resources. +The empty string represents the core API group.
resources
+[]string +
+ Resources is a list of resources this rule applies to. + +For example: +'pods' matches pods. +'pods/log' matches the log subresource of pods. +'∗' matches all resources and their subresources. +'pods/∗' matches all subresources of pods. +'∗/scale' matches all scale subresources. + +If wildcard is present, the validation rule will ensure resources do not +overlap with each other. + +An empty list implies all resources and subresources in this API groups apply.
resourceNames
+[]string +
+ ResourceNames is a list of resource instance names that the policy matches. +Using this field requires Resources to be specified. +An empty list implies that every instance of the resource is matched.
+ + + +## `Level` {#audit-k8s-io-v1-Level} + +(Alias of `string`) + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +Level defines the amount of information logged during auditing + + + + + +## `ObjectReference` {#audit-k8s-io-v1-ObjectReference} + + + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + + +ObjectReference contains enough information to let you inspect or modify the referred object. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
resource
+string +
+ No description provided. +
namespace
+string +
+ No description provided. +
name
+string +
+ No description provided. +
uid
+k8s.io/apimachinery/pkg/types.UID +
+ No description provided. +
apiGroup
+string +
+ APIGroup is the name of the API group that contains the referred object. +The empty string represents the core API group.
apiVersion
+string +
+ APIVersion is the version of the API group that contains the referred object.
resourceVersion
+string +
+ No description provided. +
subresource
+string +
+ No description provided. +
+ + + +## `PolicyRule` {#audit-k8s-io-v1-PolicyRule} + + + + +**Appears in:** + +- [Policy](#audit-k8s-io-v1-Policy) + + +PolicyRule maps requests based off metadata to an audit Level. +Requests must match the rules of every field (an intersection of rules). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
level [Required]
+Level +
+ The Level that requests matching this rule are recorded at.
users
+[]string +
+ The users (by authenticated user name) this rule applies to. +An empty list implies every user.
userGroups
+[]string +
+ The user groups this rule applies to. A user is considered matching +if it is a member of any of the UserGroups. +An empty list implies every user group.
verbs
+[]string +
+ The verbs that match this rule. +An empty list implies every verb.
resources
+[]GroupResources +
+ Resources that this rule matches. An empty list implies all kinds in all API groups.
namespaces
+[]string +
+ Namespaces that this rule matches. +The empty string "" matches non-namespaced resources. +An empty list implies every namespace.
nonResourceURLs
+[]string +
+ NonResourceURLs is a set of URL paths that should be audited. +∗s are allowed, but only as the full, final step in the path. +Examples: + "/metrics" - Log requests for apiserver metrics + "/healthz∗" - Log all health checks
omitStages
+[]Stage +
+ OmitStages is a list of stages for which no events are created. Note that this can also +be specified policy wide in which case the union of both are omitted. +An empty list means no restrictions will apply.
+ + + +## `Stage` {#audit-k8s-io-v1-Stage} + +(Alias of `string`) + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + +- [Policy](#audit-k8s-io-v1-Policy) + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +Stage defines the stages in request handling that audit events may be generated. + + + + diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md b/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100644 index 0000000000..9094ab70e6 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,5 @@ +--- +title: "kubeadmによる管理" +weight: 10 +--- + diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md new file mode 100644 index 0000000000..bb06ebe5db --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -0,0 +1,269 @@ +--- +title: kubeadmによる証明書管理 +content_type: task +weight: 10 +--- + + + +{{< feature-state for_k8s_version="v1.15" state="stable" >}} + +[kubeadm](/docs/reference/setup-tools/kubeadm/)で生成されたクライアント証明書は1年で失効します。 +このページでは、kubeadmで証明書の更新を管理する方法について説明します。 + +## {{% heading "prerequisites" %}} + +[KubernetesにおけるPKI証明書と要件](/docs/setup/best-practices/certificates/)を熟知している必要があります。 + + + +## カスタム証明書の使用 {#custom-certificates} + +デフォルトでは、kubeadmはクラスターの実行に必要なすべての証明書を生成します。 +独自の証明書を提供することで、この動作をオーバーライドできます。 + +そのためには、`--cert-dir`フラグまたはkubeadmの`ClusterConfiguration`の`certificatesDir`フィールドで指定された任意のディレクトリに配置する必要があります。 +デフォルトは`/etc/kubernetes/pki`です。 + +`kubeadm init` を実行する前に与えられた証明書と秘密鍵のペアが存在する場合、kubeadmはそれらを上書きしません。 +つまり、例えば既存のCAを`/etc/kubernetes/pki/ca.crt`と`/etc/kubernetes/pki/ca.key`にコピーすれば、kubeadmは残りの証明書に署名する際、このCAを使用できます。 + +## 外部CAモード {#external-ca-mode} + +また、`ca.crt`ファイルのみを提供し、`ca.key`ファイルを提供しないことも可能です(これはルートCAファイルのみに有効で、他の証明書ペアには有効ではありません)。 +他の証明書とkubeconfigファイルがすべて揃っている場合、kubeadmはこの状態を認識し、外部CAモードを有効にします。 +kubeadmはディスク上のCAキーがなくても処理を進めます。 + +代わりに、Controller-managerをスタンドアロンで、`--controllers=csrsigner`と実行し、CA証明書と鍵を指し示します。 + +[PKI certificates and requirements](/docs/setup/best-practices/certificates/)には、外部CAを使用するためのクラスターのセットアップに関するガイダンスが含まれています。 + +## 証明書の有効期限の確認 + +`check-expiration`サブコマンドを使うと、証明書の有効期限を確認することができます。 + +``` +kubeadm certs check-expiration +``` + +このような出力になります: + +``` +CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED +admin.conf Dec 30, 2020 23:36 UTC 364d no +apiserver Dec 30, 2020 23:36 UTC 364d ca no +apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no +apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no +controller-manager.conf Dec 30, 2020 23:36 UTC 364d no +etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no +etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no +etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no +front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no +scheduler.conf Dec 30, 2020 23:36 UTC 364d no + +CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED +ca Dec 28, 2029 23:36 UTC 9y no +etcd-ca Dec 28, 2029 23:36 UTC 9y no +front-proxy-ca Dec 28, 2029 23:36 UTC 9y no +``` + +このコマンドは、`/etc/kubernetes/pki`フォルダ内のクライアント証明書と、kubeadmが使用するKUBECONFIGファイル(`admin.conf`,`controller-manager.conf`,`scheduler.conf`)に埋め込まれたクライアント証明書の有効期限/残余時間を表示します。 + +また、証明書が外部管理されている場合、kubeadmはユーザーに通知します。この場合、ユーザーは証明書の更新を手動または他のツールを使用して管理する必要があります。 + +{{< warning >}} +`kubeadm`は外部CAによって署名された証明書を管理することができません。 +{{< /warning >}} + +{{< note >}} +kubeadmは`/var/lib/kubelet/pki`以下にあるローテート可能な証明書でkubeletの[証明書の自動更新](/docs/task/tls/certificate-rotation/)を構成するので`kubelet.conf`は上記のリストに含まれません。 + +期限切れのkubeletクライアント証明書を修復するには、[Kubelet クライアント証明書のローテーションに失敗しました](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)を参照ください。 +{{< /note >}} + +{{< warning >}} +kubeadm version 1.17より前の`kubeadm init`で作成したノードでは、`kubelet.conf`の内容を手動で変更しなければならないという[bug](https://github.com/kubernetes/kubeadm/issues/1753)が存在します。 + +`kubeadm init`が終了したら、`client-certificate-data`と`client-key-data`を置き換えて、ローテーションされたkubeletクライアント証明書を指すように`kubelet.conf`を更新してください。 + +```yaml +client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem +client-key: /var/lib/kubelet/pki/kubelet-client-current.pem +``` +{{< /warning >}} + +## 証明書の自動更新 + +kubeadmはコントロールプレーンの[アップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)時にすべての証明書を更新します。 + +この機能は、最もシンプルなユースケースに対応するために設計されています。 +証明書の更新に特別な要件がなく、Kubernetesのバージョンアップを定期的に行う場合(各アップグレードの間隔が1年未満)、kubeadmがクラスターを最新かつ適度に安全に保つための処理を行います。 + +{{< note >}} +安全性を維持するために、クラスターを頻繁にアップグレードすることがベストプラクティスです。 +{{< /note >}} + +証明書の更新に関してより複雑な要求がある場合は、`--certificate-renewal=false`を`kubeadm upgrade apply`や`kubeadm upgrade node`に渡して、デフォルトの動作から外れるようにすることができます。 + +{{< warning >}} +kubeadmバージョン1.17より前のバージョンでは、`kubeadm upgrade node`コマンドの`--certificate-renewal`のデフォルト値が`false`になっているという[bug(https://github.com/kubernetes/kubeadm/issues/1818)]問題があります。 +この場合、明示的に`--certificate-renewal=true`を設定する必要があります。 +{{< /warning >}} + +## 手動による証明書更新 + +`kubeadm certs renew` コマンドを使えば、いつでも証明書を手動で更新することができます。 + +このコマンドは`/etc/kubernetes/pki`に格納されているCA(またはfront-proxy-CA)の証明書と鍵を使って更新を行います。 + +コマンド実行後、コントロールプレーンのPodを再起動する必要があります。 +これは、現在すべてのコンポーネントと証明書について動的な証明書のリロードがサポートされていないため、必要な作業です。 +[スタティックPod](/docs/tasks/configure-pod-container/static-pod/)はローカルkubeletによって管理され、API Serverによって管理されないため、kubectlで削除および再起動することはできません。 + +スタティックPodを再起動するには、一時的に`/etc/kubernetes/manifests/`からマニフェストファイルを削除して20秒間待ちます([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)の`fileCheckFrequency`値を参照してください)。 +マニフェストディレクトリにPodが無くなると、kubeletはPodを終了します。 +その後ファイルを戻して、さらに`fileCheckFrequency`期間後に、kubeletはPodを再作成し、コンポーネントの証明書更新を完了することができます。 + +{{< warning >}} +HAクラスターを実行している場合、このコマンドはすべての制御プレーンノードで実行する必要があります。 +{{< /warning >}} + +{{< note >}} +`certs renew`は、属性(Common Name、Organization、SANなど)の信頼できるソースとして、kubeadm-config ConfigMapではなく、既存の証明書を使用します。両者を同期させておくことが強く推奨されます。 +{{< /note >}} + +`kubeadm certs renew` は以下のオプションを提供します: + +Kubernetesの証明書は通常1年後に有効期限を迎えます。 + +- `--csr-only`を使用すると、証明書署名要求を生成して外部CAとの証明書を更新することができます(実際にはその場で証明書を更新しません)。詳しくは次の段落を参照してください。 + +- また、すべての証明書を更新するのではなく、1つの証明書を更新することも可能です。 + +## Kubernetes certificates APIによる証明書の更新 + +ここでは、Kubernetes certificates APIを使用して手動で証明書更新を実行する方法について詳しく説明します。 + +{{< caution >}} +これらは、組織の証明書インフラをkubeadmで構築されたクラスターに統合する必要があるユーザー向けの上級者向けのトピックです。 +kubeadmのデフォルトの設定で満足できる場合は、代わりにkubeadmに証明書を管理させる必要があります。 +{{< /caution >}} + +### 署名者の設定 + +Kubernetesの認証局は、そのままでは機能しません。 +[cert-manager](https://cert-manager.io/docs/configuration/ca/)などの外部署名者を設定するか、組み込みの署名者を使用することができます。 + +ビルトインサイナーは[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)に含まれるものです。 + +ビルトインサイナーを有効にするには、`--cluster-signing-cert-file`と`--cluster-signing-key-file`フラグを渡す必要があります。 + +新しいクラスターを作成する場合は、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。 + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +controllerManager: + extraArgs: + cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt + cluster-signing-key-file: /etc/kubernetes/pki/ca.key +``` + +### 証明書署名要求の作成 (CSR) + +Kubernetes APIでのCSR作成については、[Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)を参照ください。 + +## 外部CAによる証明書の更新 + +ここでは、外部認証局を利用して手動で証明書更新を行う方法について詳しく説明します。 + +外部CAとの連携を強化するために、kubeadmは証明書署名要求(CSR)を生成することもできます。 +CSRとは、クライアント用の署名付き証明書をCAに要求することを表します。 +kubeadmの用語では、通常ディスク上のCAによって署名される証明書をCSRとして生成することができます。しかし、CAはCSRとして生成することはできません。 + +### 証明書署名要求の作成 (CSR) + +`kubeadm certs renew --csr-only`で証明書署名要求を作成することができます。 + +CSRとそれに付随する秘密鍵の両方が出力されます。 +ディレクトリを`--csr-dir`で渡すと、指定した場所にCSRを出力することができます。 +`csr-dir`を指定しない場合は、デフォルトの証明書ディレクトリ(`/etc/kubernetes/pki`)が使用されます。 + +証明書は`kubeadm certs renew --csr-only`で更新することができます。 +`kubeadm init`と同様に、`--csr-dir`フラグで出力先ディレクトリを指定することができます。 + +CSRには、証明書の名前、ドメイン、IPが含まれますが、用途は指定されません。 +証明書を発行する際に、[正しい証明書の使用法](/docs/setup/best-practices/certificates/#all-certificates)を指定するのはCAの責任です。 + +* `openssl`では、[`openssl ca`コマンド](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)を使って行います。 + +* `cfssl`では、[configファイルのusages](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)で指定します。 + +お好みの方法で証明書に署名した後、証明書と秘密鍵をPKIディレクトリ(デフォルトでは`/etc/kubernetes/pki`)にコピーする必要があります。 + +## 認証局(CA)のローテーション {#certificate-authority-rotation} + +Kubeadmは、CA証明書のローテーションや交換を最初からサポートしているわけではありません。 + +CAの手動ローテーションや交換についての詳細は、[manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/)を参照してください。 + +## 署名付きkubeletサービング証明書の有効化 {#kubelet-serving-certs} + +デフォルトでは、kubeadmによって展開されるkubeletサービング証明書は自己署名されています。 +これは、[metrics-server](https://github.com/kubernetes-sigs/metrics-server)のような外部サービスからキューブレットへの接続がTLSで保護されないことを意味します。 +新しいkubeadmクラスター内のkubeletが適切に署名されたサービング証明書を取得するように設定するには、`kubeadm init`に以下の最小限の設定を渡す必要があります。 + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +serverTLSBootstrap: true +``` + +すでにクラスターを作成している場合は、以下の手順で適応させる必要があります。 + + - kube-system` ネームスペースにある `kubelet-config-{{< skew latestVersion >}}` ConfigMapを見つけて編集します。 + +そのConfigMapの`kubelet`キーの値として[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)ドキュメントを指定します。KubeletConfigurationドキュメントを編集し、`serverTLSBootstrap: true`を設定します。 + +- 各ノードで、`/var/lib/kubelet/config.yaml`に`serverTLSBootstrap: true`フィールドを追加し、`systemctl restart kubelet`でkubeletを再起動します。 + +`serverTLSBootstrap: true`フィールドは、kubeleサービングのブートストラップを有効にします。 +証明書を`certificates.k8s.io`APIにリクエストすることで、証明書を発行することができます。 + +既知の制限事項として、これらの証明書のCSR(Certificate Signing Requests)はkube-controller-managerのデフォルトサイナーによって自動的に承認されないことがあります。 +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers) を参照してください。 + +これには、ユーザーまたはサードパーティーのコントローラーからのアクションが必要です。 + +これらのCSRは、以下を使用して表示できます: + +```shell +kubectl get csr +NAME AGE SIGNERNAME REQUESTOR CONDITION +csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending +csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending +``` + +承認するためには、次のようにします: +```shell +kubectl certificate approve +``` + +デフォルトでは、これらのサービング証明書は1年後に失効します。 + +Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に設定します。これは有効期限が切れる間際に、サービング証明書のための新しいCSRセットを作成し、ローテーションを完了するために承認する必要があることを意味します。 + +詳しくは[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)をご覧ください。 + +これらのCSRを自動的に承認するためのソリューションをお探しの場合は、以下をお勧めします。 +クラウドプロバイダーに連絡し、ノードの識別をアウトオブバンドのメカニズムで行うCSRの署名者がいるかどうか尋ねてください。 + +{{% thirdparty-content %}} + +サードパーティーのカスタムコントローラーを使用することができます。 +- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver) + +このようなコントローラーは、CSRのCommonNameを検証するだけでなく、要求されたIPやドメイン名も検証しなければ、安全なメカニズムとは言えません。これにより、kubeletクライアント証明書にアクセスできる悪意のあるアクターが、任意のIPやドメイン名に対してサービング証明書を要求するCSRを作成することを防ぐことができます。 diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md new file mode 100644 index 0000000000..a6d297bdd8 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -0,0 +1,45 @@ +--- +title: ノードで使用されているコンテナランタイムの確認 +content_type: task +weight: 10 +--- + + + +このページでは、クラスター内のノードが使用している[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)を確認する手順を概説しています。 + +クラスターの実行方法によっては、ノード用のコンテナランタイムが事前に設定されている場合と、設定する必要がある場合があります。 +マネージドKubernetesサービスを使用している場合、ノードに設定されているコンテナランタイムを確認するためのベンダー固有の方法があるかもしれません。 +このページで説明する方法は、`kubectl`の実行が許可されていればいつでも動作するはずです。 + +## {{% heading "prerequisites" %}} + +`kubectl`をインストールし、設定します。詳細は[ツールのインストール](/ja/docs/tasks/tools/#kubectl)の項を参照してください。 + +## ノードで使用されているコンテナランタイムの確認 + +ノードの情報を取得して表示するには`kubectl`を使用します: + +```shell +kubectl get nodes -o wide +``` + +出力は以下のようなものです。列`CONTAINER-RUNTIME`には、ランタイムとそのバージョンが出力されます。 + +```none +# For dockershim +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.16.15 docker://19.3.1 +node-2 Ready v1.16.15 docker://19.3.1 +node-3 Ready v1.16.15 docker://19.3.1 +``` + +```none +# For containerd +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.19.6 containerd://1.4.1 +node-2 Ready v1.19.6 containerd://1.4.1 +node-3 Ready v1.19.6 containerd://1.4.1 +``` + +コンテナランタイムについては、[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)のページで詳細を確認することができます。 diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md new file mode 100644 index 0000000000..b020b9c0b2 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -0,0 +1,233 @@ +--- +content_type: concept +title: 監査 +--- + + + +Kubernetesの監査はクラスター内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 +クラスターはユーザー、Kubernetes APIを使用するアプリケーション、 +およびコントロールプレーン自体によって生成されたアクティビティなどを監査します。 + +監査により、クラスター管理者は以下の質問に答えることができます: + + - 何が起きたのか? + - いつ起こったのか? + - 誰がそれを始めたのか? + - 何のために起こったのか? + - それはどこで観察されたのか? + - それはどこから始まったのか? + - それはどこへ向かっていたのか? + + + +監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 +各リクエストの実行の各段階で、監査イベントが生成されます。 +ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定し、 +バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 + +各リクエストは関連する _stage_ で記録されます。 +定義されたステージは以下の通りです: + +- `RequestReceived` - 監査ハンドラーがリクエストを受信すると同時に生成されるイベントのステージ。 + つまり、ハンドラーチェーンに委譲される前に生成されるイベントのステージです。 +- `ResponseStarted` - レスポンスヘッダーが送信された後、レスポンスボディが送信される前のステージです。 + このステージは長時間実行されるリクエスト(watchなど)でのみ発生します。 +- `ResponseComplete` - レスポンスボディの送信が完了して、それ以上のバイトは送信されません。 +- `Panic` - パニックが起きたときに発生するイベント。 + +{{< note >}} +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)APIオブジェクトとは異なります。 +{{< /note >}} + +監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリー消費量が増加します。 +メモリーの消費量は、監査ログ機能の設定によって異なります。 + +## 監査ポリシー + +監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 +監査ポリシーのオブジェクト構造は、[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 + +イベントが処理されると、そのイベントは順番にルールのリストと比較されます。 +最初のマッチングルールは、イベントの監査レベルを設定します。 + +定義されている監査レベルは: + +- `None` - ルールに一致するイベントを記録しません。 +- `Metadata` - リクエストのメタデータ(リクエストしたユーザー、タイムスタンプ、リソース、動作など)を記録しますが、リクエストやレスポンスのボディは記録しません。 +- `Request` - ログイベントのメタデータとリクエストボディは表示されますが、レスポンスボディは表示されません。 + これは非リソースリクエストには適用されません。 +- `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 + 非リソースリクエストには適用されません。 + +`audit-policy-file`フラグを使って、ポリシーを記述したファイルを `kube-apiserver`に渡すことができます。 +このフラグが省略された場合イベントは記録されません。 +監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 +ルールがない(0)ポリシーは不当なものとして扱われます。 + +以下は監査ポリシーファイルの例です: + +{{< codenew file="audit/audit-policy.yaml" >}} + +最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata`レベルで記録することができます。 + +```yaml +# Log all requests at the Metadata level. +apiVersion: audit.k8s.io/v1 +kind: Policy +rules: +- level: Metadata +``` + +独自の監査プロファイルを作成する場合は、Google Container-Optimized OSの監査プロファイルを出発点として使用できます。 +監査ポリシーファイルを生成する[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)スクリプトを確認することができます。 +スクリプトを直接見ることで、監査ポリシーファイルのほとんどを見ることができます。 + +また、定義されているフィールドの詳細については、[Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)を参照できます。 + +## 監査バックエンド + +監査バックエンドは監査イベントを外部ストレージに永続化します。 +kube-apiserverには2つのバックエンドが用意されています。 + +- イベントをファイルシステムに書き込むログバックエンド +- 外部のHTTP APIにイベントを送信するWebhookバックエンド + +いずれの場合も、監査イベントはKubernetes API[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)で定義されている構造に従います。 + + +{{< note >}} +パッチの場合、リクエストボディはパッチ操作を含むJSON配列であり、適切なKubernetes APIオブジェクトを含むJSONオブジェクトではありません。 +例えば、以下のリクエストボディは`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`に対する有効なパッチリクエストです。 + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` + +{{< /note >}} + +### ログバックエンド + +ログバックエンドは監査イベントを[JSONlines](https://jsonlines.org/)形式のファイルに書き込みます。 +以下の `kube-apiserver` フラグを使ってログ監査バックエンドを設定できます。 + +- `--audit-log-path` は、ログバックエンドが監査イベントを書き込む際に使用するログファイルのパスを指定します。 + このフラグを指定しないと、ログバックエンドは無効になります。`-` は標準出力を意味します。 +- `--audit-log-maxage` は、古い監査ログファイルを保持する最大日数を定義します。 +- `audit-log-maxbackup`は、保持する監査ログファイルの最大数を定義します。 +- `--audit-log-maxsize` は、監査ログファイルがローテーションされるまでの最大サイズをメガバイト単位で定義します。 + +クラスターのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 +例えば: +```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ + --audit-log-path=/var/log/audit.log +``` + +それからボリュームをマウントします: +```yaml +... +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false +``` + +最後に`hostPath`を設定します: +```yaml +... +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/audit.log + type: FileOrCreate + +``` + +### Webhookバックエンド + +Webhook監査バックエンドは、監査イベントをリモートのWeb APIに送信しますが、 +これは認証手段を含むKubernetes APIの形式であると想定されます。 + +Webhook監査バックエンドを設定するには、以下のkube-apiserverフラグを使用します。 + +- `--audit-webhook-config-file` は、Webhookの設定ファイルのパスを指定します。 + webhookの設定は、事実上特化した[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)です。 +- `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 + それ以降のリクエストは、指数関数的なバックオフで再試行されます。 + +Webhookの設定ファイルは、kubeconfig形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 + +## イベントバッチ {#batching} + +ログバックエンドとwebhookバックエンドの両方がバッチ処理をサポートしています。 +webhookを例に、利用可能なフラグの一覧を示します。 +ログバックエンドで同じフラグを取得するには、フラグ名の`webhook`を`log`に置き換えてください。 +デフォルトでは、バッチングは`webhook`では有効で、`log`では無効です。 +同様に、デフォルトではスロットリングは `webhook` で有効で、`log`では無効です。 + +- `--audit-webhook-mode` は、バッファリング戦略を定義します。以下のいずれかとなります。 + - `batch` - イベントをバッファリングして、非同期にバッチ処理します。これがデフォルトです。 + - `blocking` - 個々のイベントを処理する際に、APIサーバーの応答をブロックします。 + - `blocking-strict` - blockingと同じですが、RequestReceivedステージでの監査ログに失敗した場合は RequestReceivedステージで監査ログに失敗すると、kube-apiserverへのリクエスト全体が失敗します。 + +以下のフラグは `batch` モードでのみ使用されます: + +- `--audit-webhook-batch-buffer-size`は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 + 入力イベントの割合がバッファをオーバーフローすると、イベントはドロップされます。 +- `--audit-webhook-batch-max-size`は、1つのバッチに入れるイベントの最大数を定義します。 +- `--audit-webhook-batch-max-wait`は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 +- `--audit-webhook-batch-throttle-qps`は、1秒あたりに生成されるバッチの最大平均数を定義します。 +- `--audit-webhook-batch-throttle-burst`は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 + + +## パラメーターチューニング + +パラメーターは、APIサーバーの負荷に合わせて設定してください。 + +例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 +1つのバッチに最大100個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 +バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファーサイズを設定する必要があります。 + +10バッチ、または1000イベントとなります。 + +しかし、ほとんどの場合デフォルトのパラメーターで十分であり、手動で設定する必要はありません。 +kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 + +- `apiserver_audit_event_total`メトリックには、エクスポートされた監査イベントの合計数が含まれます。 +- `apiserver_audit_error_total`メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 + +### ログエントリー・トランケーション {#truncate} + +logバックエンドとwebhookバックエンドは、ログに記録されるイベントのサイズを制限することをサポートしています。 + +例として、logバックエンドで利用可能なフラグの一覧を以下に示します + +- `audit-log-truncate-enabled`イベントとバッチの切り捨てを有効にするかどうかです。 +- `audit-log-truncate-max-batch-size`バックエンドに送信されるバッチのバイト単位の最大サイズ。 +- `audit-log-truncate-max-event-size`バックエンドに送信される監査イベントのバイト単位の最大サイズです。 + +デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 + +## {{% heading "whatsnext" %}} + +* [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). +* [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +* [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md new file mode 100644 index 0000000000..3e3adbc7c3 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -0,0 +1,407 @@ +--- +title: crictlによるKubernetesノードのデバッグ +content_type: task +--- + + + + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + +`crictl`はCRI互換のコンテナランタイム用のコマンドラインインターフェイスです。 + +これを使って、Kubernetesノード上のコンテナランタイムやアプリケーションの検査やデバッグを行うことができます。 +`crictl`とそのソースコードは[cri-tools](https://github.com/kubernetes-sigs/cri-tools)リポジトリにホストされています。 + +## {{% heading "prerequisites" %}} + + +`crictl`にはCRIランタイムを搭載したLinuxが必要です。 + + + + + +## crictlのインストール + +cri-toolsの[リリースページ](https://github.com/kubernetes-sigs/cri-tools/releases)から、いくつかの異なるアーキテクチャ用の圧縮アーカイブ`crictl`をダウンロードできます。 + +お使いのKubernetesのバージョンに対応するバージョンをダウンロードしてください。 +それを解凍してシステムパス上の`/usr/local/bin/`などの場所に移動します。 + +## 一般的な使い方 + +`crictl`コマンドにはいくつかのサブコマンドとランタイムフラグがあります。 +詳細は`crictl help`または`crictl help`を参照してください。 +`crictl`はデフォルトでは`unix:///var/run/dockershim.sock`に接続します。 + +他のランタイムの場合は、複数の異なる方法でエンドポイントを設定することができます: + +- フラグ`--runtime-endpoint`と`--image-endpoint`の設定により +- 環境変数`CONTAINER_RUNTIME_ENDPOINT`と`IMAGE_SERVICE_ENDPOINT`の設定により +- 設定ファイル`--config=/etc/crictl.yaml`でエンドポイントの設定により + +また、サーバーに接続する際のタイムアウト値を指定したり、デバッグを有効/無効にしたりすることもできます。 +これには、設定ファイルで`timeout`や`debug`を指定するか、`--timeout`や`--debug`のコマンドラインフラグを使用します。 + +現在の設定を表示または編集するには、`/etc/crictl.yaml`の内容を表示または編集します。 + + +```shell +cat /etc/crictl.yaml +runtime-endpoint: unix:///var/run/dockershim.sock +image-endpoint: unix:///var/run/dockershim.sock +timeout: 10 +debug: true +``` + +## crictlコマンドの例 + +以下の例では、いくつかの`crictl`コマンドとその出力例を示しています。 + +{{< warning >}} +実行中のKubernetesクラスターに`crictl`を使ってポッドのサンドボックスやコンテナを作成しても、Kubeletは最終的にそれらを削除します。`crictl` は汎用のワークフローツールではなく、デバッグに便利なツールです。 +{{< /warning >}} + +### podsの一覧 + +すべてのポッドをリストアップ: + +```shell +crictl pods +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 +4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 +a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0 +919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0 +``` + +Podを名前でリストアップします: + +```shell +crictl pods --name nginx-65899c769f-wv2gp +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +Podをラベルでリストアップします: + +```shell +crictl pods --label run=nginx +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +### イメージの一覧 + +すべてのイメージをリストアップします: + +```shell +crictl images +``` + +出力はこのようになります: + +``` +IMAGE TAG IMAGE ID SIZE +busybox latest 8c811b4aec35f 1.15MB +k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB +k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB +nginx latest cd5239a0906a6 109MB +``` + +イメージをリポジトリでリストアップします: + +```shell +crictl images nginx +``` + +出力はこのようになります: + +``` +IMAGE TAG IMAGE ID SIZE +nginx latest cd5239a0906a6 109MB +``` + +イメージのIDのみをリストアップします: + +```shell +crictl images -q +``` + +出力はこのようになります: + +``` +sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a +sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 +sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e +sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 +``` + +### List containers + +すべてのコンテナをリストアップします: + +```shell +crictl ps -a +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 +9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0 +``` + +ランニングコンテナをリストアップします: + +``` +crictl ps +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0 +``` + +### 実行中のコンテナでコマンドの実行 + +```shell +crictl exec -i -t 1f73f2d81bf98 ls +``` + +出力はこのようになります: + +``` +bin dev etc home proc root sys tmp usr var +``` + +### コンテナログの取得 + +すべてのコンテナログを取得します: + +```shell +crictl logs 87d3992f84f74 +``` + +出力はこのようになります: + +``` +10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +最新の`N`行のログのみを取得します: + +```shell +crictl logs --tail=1 87d3992f84f74 +``` + +出力はこのようになります: + +``` +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +### Podサンドボックスの実行 + +`crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。 +稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 + +1. 以下のようなJSONファイルを作成します: + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "logDirectory": "/tmp", + "linux": { + } + } + ``` + +2. JSONを適用してサンドボックスを実行するには、`crictl runp`コマンドを使用します: + + ```shell + crictl runp pod-config.json + ``` + + サンドボックスのIDが返されます。 + +### コンテナの作成 + +コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。 +稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 + +1. busyboxイメージをプルします: + + ```shell + crictl pull busybox + Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 + ``` + +2. Podとコンテナのコンフィグを作成します: + + **Pod config**: + ```yaml + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + + **Container config**: + ```yaml + { + "metadata": { + "name": "busybox" + }, + "image":{ + "image": "busybox" + }, + "command": [ + "top" + ], + "log_path":"busybox.log", + "linux": { + } + } + ``` + +3. 先に作成されたPodのID、コンテナの設定ファイル、Podの設定ファイルを渡して、コンテナを作成します。コンテナのIDが返されます。 + + ```shell + crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json + ``` + +4. すべてのコンテナをリストアップし、新しく作成されたコンテナの状態が`Created`に設定されていることを確認します: + + ```shell + crictl ps -a + ``` + + 出力はこのようになります: + ``` + CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT + 3e025dd50a72d busybox 32 seconds ago Created busybox 0 + ``` + +### コンテナの起動 + +コンテナを起動するには、そのコンテナのIDを`crictl start`に渡します: + +```shell +crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +出力はこのようになります: + +``` +3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +コンテナの状態が「Running」に設定されていることを確認します: + +```shell +crictl ps +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + + + +詳しくは[kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)をご覧ください。 + +## docker cliからcrictlへのマッピング + +以下のマッピング表の正確なバージョンは、`docker cli v1.40`と`crictl v1.19.0`のものです。 +この一覧はすべてを網羅しているわけではないことに注意してください。 +たとえば、`docker cli`の実験的なコマンドは含まれていません。 + +{{< note >}} +CRICTLの出力形式はDocker CLIと似ていますが、いくつかのCLIでは列が欠けています。 +{{< /note >}} + +### デバッグ情報の取得 + +{{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} +docker cli | crictl | 説明 | サポートされていない機能 +-- | -- | -- | -- +`attach` | `attach` | 実行中のコンテナにアタッチ | `--detach-keys`, `--sig-proxy` +`exec` | `exec` | 実行中のコンテナでコマンドの実行 | `--privileged`, `--user`, `--detach-keys` +`images` | `images` | イメージのリストアップ |   +`info` | `info` | システム全体の情報の表示 |   +`inspect` | `inspect`, `inspecti` | コンテナ、イメージ、タスクの低レベルの情報を返します |   +`logs` | `logs` | コンテナのログを取得します | `--details` +`ps` | `ps` | コンテナのリストアップ |   +`stats` | `stats` | コンテナのリソース使用状況をライブで表示 | Column: NET/BLOCK I/O, PIDs +`version` | `version` | ランタイム(Docker、ContainerD、その他)のバージョン情報を表示します |   +{{< /table >}} + +### 変更を行います + +{{< table caption="mapping from docker cli to crictl - perform changes" >}} +docker cli | crictl | 説明 | サポートされていない機能 +-- | -- | -- | -- +`create` | `create` | 新しいコンテナを作成します |   +`kill` | `stop` (timeout = 0) | 1つ以上の実行中のコンテナを停止します | `--signal` +`pull` | `pull` | レジストリーからイメージやリポジトリをプルします | `--all-tags`, `--disable-content-trust` +`rm` | `rm` | 1つまたは複数のコンテナを削除します |   +`rmi` | `rmi` | 1つまたは複数のイメージを削除します |   +`run` | `run` | 新しいコンテナでコマンドを実行 |   +`start` | `start` | 停止した1つまたは複数のコンテナを起動 | `--detach-keys` +`stop` | `stop` | 実行中の1つまたは複数のコンテナの停止 |   +`update` | `update` | 1つまたは複数のコンテナの構成を更新 | `--restart`、`--blkio-weight`とその他 +{{< /table >}} + +### crictlでのみ対応 + +{{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} +crictl | 説明 +-- | -- +`imagefsinfo` | イメージファイルシステムの情報を返します +`inspectp` | 1つまたは複数のPodの状態を表示します +`port-forward` | ローカルポートをPodに転送します +`runp` | 新しいPodを実行します +`rmp` | 1つまたは複数のPodを削除します +`stopp` | 稼働中の1つまたは複数のPodを停止します +{{< /table >}} diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md new file mode 100644 index 0000000000..9cc49e3924 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -0,0 +1,257 @@ +--- +title: Secretsで安全にクレデンシャルを配布する +content_type: task +weight: 50 +min-kubernetes-server-version: v1.6 +--- + + +このページでは、パスワードや暗号化キーなどの機密データをPodに安全に注入する方法を紹介します。 + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +### 機密データをbase64でエンコードする + +ユーザー名`my-app`とパスワード`39528$vdg7Jb`の2つの機密データが必要だとします。 +まず、base64エンコーディングツールを使って、ユーザ名とパスワードをbase64表現に変換します。 +ここでは、手軽に入手できるbase64プログラムを使った例を紹介します: + +```shell +echo -n 'my-app' | base64 +echo -n '39528$vdg7Jb' | base64 +``` + +出力結果によると、ユーザ名のbase64表現は`bXktYXBw`で、パスワードのbase64表現は`Mzk1MjgkdmRnN0pi`です。 + +{{< caution >}} +OSから信頼されているローカルツールを使用することで、外部ツールのセキュリティリスクを低減することができます。 +{{< /caution >}} + + + + +## Secretを作成する + +以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイルです: + +{{< codenew file="pods/inject/secret.yaml" >}} + +1. Secret を作成する + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml + ``` + +1. Secretの情報を取得する + + ```shell + kubectl get secret test-secret + ``` + + 出力: + + ``` + NAME TYPE DATA AGE + test-secret Opaque 2 1m + ``` + +1. Secretの詳細な情報を取得する: + + ```shell + kubectl describe secret test-secret + ``` + + 出力: + + ``` + Name: test-secret + Namespace: default + Labels: + Annotations: + + Type: Opaque + + Data + ==== + password: 13 bytes + username: 7 bytes + ``` + +### kubectlでSecretを作成する + +base64エンコードの手順を省略したい場合は、`kubectl create secret`コマンドで同じSecretを作成することができます。 + +例えば: + +```shell +kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' +``` + +先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、`kubectl create secret`の方が便利です。 + + +## Volumeにある機密情報をアクセスするPodを作成する + +これはPodの作成に使用できる設定ファイルです。 + +{{< codenew file="pods/inject/secret-pod.yaml" >}} + +1. Podを作成する: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml + ``` + +1. Podの`STATUS`が`Running`であるのを確認する: + + ```shell + kubectl get pod secret-test-pod + ``` + + 出力: + ``` + NAME READY STATUS RESTARTS AGE + secret-test-pod 1/1 Running 0 42m + ``` + +1. Podの中にあるコンテナにシェルを実行する + + ```shell + kubectl exec -i -t secret-test-pod -- /bin/bash + ``` + +1. 機密データは `/etc/secret-volume` にマウントされたボリュームを介してコンテナに公開されます。 + + ディレクトリ `/etc/secret-volume` 中のファイルの一覧を確認する: + ```shell + # Run this in the shell inside the container + ls /etc/secret-volume + ``` + `password`と`username` 2つのファイル名が出力される: + ``` + password username + ``` + +1. `username` と `password` ファイルの中身を表示する: + + ```shell + # Run this in the shell inside the container + echo "$( cat /etc/secret-volume/username )" + echo "$( cat /etc/secret-volume/password )" + + ``` + 出力: + ``` + my-app + 39528$vdg7Jb + ``` + +## Secretでコンテナの環境変数を定義する + +### 単一のSecretでコンテナの環境変数を定義する + +* Secretの中でkey-valueペアで環境変数を定義する: + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + ``` + +* Secretで定義された`backend-username`の値をPodの環境変数`SECRET_USERNAME`に割り当てます。 + + {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}} + +* Podを作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml + ``` + +* コンテナの環境変数`SECRET_USERNAME`の中身を表示する: + + ```shell + kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' + ``` + + 出力: + ``` + backend-admin + ``` + +### 複数のSecretからコンテナの環境変数を定義する + +* 前述の例と同様に、まずSecretを作成します: + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + kubectl create secret generic db-user --from-literal=db-username='db-admin' + ``` + +* Podの中で環境変数を定義する: + + {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}} + +* Podを作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml + ``` + +* コンテナの環境変数を表示する: + + ```shell + kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' + ``` + 出力: + ``` + DB_USERNAME=db-admin + BACKEND_USERNAME=backend-admin + ``` + + +## Secretのすべてのkey-valueペアを環境変数として設定する + +{{< note >}} +この機能は Kubernetes v1.6 以降から利用可能 +{{< /note >}} + +* 複数のkey-valueペアを含むSecretを作成する + + ```shell + kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' + ``` + +* envFromを使用してSecretのすべてのデータをコンテナの環境変数として定義します。SecretのキーがPodの環境変数名になります。 + + {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} + +* Podを作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml + ``` + +* `username`と`password`コンテナの環境変数を表示する + + ```shell + kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' + ``` + + 出力: + ``` + username: my-app + password: 39528$vdg7Jb + ``` + +### 参考文献 + +* [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) +* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + +## {{% heading "whatsnext" %}} + +* [Secrets](/docs/concepts/configuration/secret/)についてもっと知る。 +* [Volumes](/docs/concepts/storage/volumes/)について知る。 diff --git a/content/ja/docs/tasks/network/validate-dual-stack.md b/content/ja/docs/tasks/network/validate-dual-stack.md index 9ab51d8701..1859d1e408 100644 --- a/content/ja/docs/tasks/network/validate-dual-stack.md +++ b/content/ja/docs/tasks/network/validate-dual-stack.md @@ -135,7 +135,7 @@ status: loadBalancer: {} ``` -`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 +`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 {{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}} @@ -173,7 +173,7 @@ status: loadBalancer: {} ``` -`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 +`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} diff --git a/content/ja/docs/tutorials/clusters/apparmor.md b/content/ja/docs/tutorials/clusters/apparmor.md index 55ec58c501..69a3063c6a 100644 --- a/content/ja/docs/tutorials/clusters/apparmor.md +++ b/content/ja/docs/tutorials/clusters/apparmor.md @@ -35,7 +35,7 @@ AppArmorを利用すれば、コンテナに許可することを制限したり gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` -2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。 +2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。 ```shell cat /sys/module/apparmor/parameters/enabled diff --git a/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml b/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml new file mode 100644 index 0000000000..f285e41932 --- /dev/null +++ b/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envvars-multiple-secrets +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: BACKEND_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username + - name: DB_USERNAME + valueFrom: + secretKeyRef: + name: db-user + key: db-username diff --git a/content/ja/examples/pods/inject/pod-secret-envFrom.yaml b/content/ja/examples/pods/inject/pod-secret-envFrom.yaml new file mode 100644 index 0000000000..eb1d3213ef --- /dev/null +++ b/content/ja/examples/pods/inject/pod-secret-envFrom.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envfrom-secret +spec: + containers: + - name: envars-test-container + image: nginx + envFrom: + - secretRef: + name: test-secret diff --git a/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml b/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml new file mode 100644 index 0000000000..af4cf8732f --- /dev/null +++ b/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: env-single-secret +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username diff --git a/content/ko/_index.html b/content/ko/_index.html index c6350f1559..34cdfe5740 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -39,8 +39,8 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}

150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는 도전

-

By Sarah Wells, Technical Director for Operations and Reliability, Financial Times

- +

Sarah Wells, Financial Times 운영 및 안정성 기술 담당 이사

+

Attend KubeCon North America on October 11-15, 2021 diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 5f4e1605dd..8306f824e9 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -144,7 +144,7 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 지원하려면, 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) 파일의 섹션에 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 파일의 섹션에 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. {{< note >}} @@ -216,7 +216,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 지원하려면 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. {{< note >}} diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..bd0cd7315d --- /dev/null +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -0,0 +1,1349 @@ +--- +title: Secrets +content_type: concept +feature: + title: Secrets e gerenciamento de configuração + description: > + Crie e atualize Secrets e configurações da aplicação sem reconstruir sua imagem + de contêiner e sem expor credenciais na configuração da sua aplicação. +weight: 30 +--- + + + +Um Secret é um objeto que contém uma pequena quantidade de informação sensível, +como senhas, tokens ou chaves. Este tipo de informação poderia, em outras +circunstâncias, ser colocada diretamente em uma configuração de +{{< glossary_tooltip term_id="pod" >}} ou em uma +{{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de +Secrets evita que você tenha de incluir dados confidenciais no seu código. + +Secrets podem ser criados de forma independente dos Pods que os consomem. Isto +reduz o risco de que o Secret e seus dados sejam expostos durante o processo de +criação, visualização e edição ou atualização de Pods. O Kubernetes e as +aplicações que rodam no seu cluster podem também tomar outras precauções com +Secrets, como por exemplo evitar a escrita de dados confidenciais em local de +armazenamento persistente (não-volátil). + +Secrets são semelhantes a +{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram +especificamente projetados para conter dados confidenciais. + +{{< caution >}} +Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema +de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa +com acesso à API ou ao etcd consegue obter ou modificar um Secret. +Além disso, qualquer pessoa que possui autorização para criar Pods em um namespace +consegue utilizar este privilégio para ler qualquer Secret naquele namespace. Isso +inclui acesso indireto, como por exemplo a permissão para criar Deployments. + +Para utilizar Secrets de forma segura, siga pelo menos as instruções abaixo: +1. [Habilite encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) para Secrets. +1. Habilite ou configure [regras de RBAC](/docs/reference/access-authn-authz/authorization/) +que restrinjam o acesso de leitura a Secrets (incluindo acesso indireto). +1. Quando apropriado, utilize mecanismos como RBAC para limitar quais perfis e +usuários possuem permissão para criar novos Secrets ou substituir Secrets +existentes. + +{{< /caution >}} + + + +## Visão Geral de Secrets + +Para utilizar um Secret, um Pod precisa referenciar o Secret. +Um Secret pode ser utilizado em um Pod de três maneiras diferentes: +- Como um [arquivo](#using-secrets-as-files-from-a-pod) em um +{{< glossary_tooltip text="volume" term_id="volume" >}} montado em um ou mais de +seus contêineres. +- Como uma [variável de ambiente](#using-secrets-as-environment-variables) em um +contêiner. +- Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o +Pod. + +A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, +os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um +mecanismo que auxilia a automação do registro de nós. + +O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um +arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são +opcionais. Os valores das chaves no campo `data` devem ser strings codificadas +no formato base64. Se a conversão para base64 não for desejável, você pode +optar por informar os dados no campo `stringData`, que aceita strings arbitrárias +como valores. + +As chaves dos campos `data` e `stringData` devem consistir de caracteres +alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` +são internamente combinados com os dados do campo `data`. Se uma chave aparece +em ambos os campos, o valor informado no campo `stringData` toma a precedência. + +## Tipos de Secrets {#secret-types} + +Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` +do objeto Secret, ou algumas opções de linha de comando equivalentes no comando +`kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para +facilitar a manipulação programática de diferentes tipos de dados confidenciais. + +O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. +Estes tipos variam em termos de validações efetuadas e limitações que o +Kubernetes impõe neles. + +| Tipo embutido | Caso de uso | +|----------------------------------------|----------------------------------------------------| +| `Opaque` | dados arbitrários definidos pelo usuário | +| `kubernetes.io/service-account-token` | token de service account (conta de serviço) | +| `kubernetes.io/dockercfg` | arquivo `~/.dockercfg` serializado | +| `kubernetes.io/dockerconfigjson` | arquivo `~/.docker/config.json` serializado | +| `kubernetes.io/basic-auth` | credenciais para autenticação básica (basic auth) | +| `kubernetes.io/ssh-auth` | credenciais para autenticação SSH | +| `kubernetes.io/tls` | dados para um cliente ou servidor TLS | +| `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | + +Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do +campo `type` como uma string não-nula em um objeto Secret. Uma string em branco +é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No +entanto, quando tipos embutidos são utilizados, você precisa atender a todos os +requisitos daquele tipo. + +### Secrets tipo Opaque + +`Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado +em um arquivo de configuração. Quando um Secret é criado usando o comando +`kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é +do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo +`Opaque`: +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +O resultado será semelhante ao abaixo: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + +A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste +caso, `0` significa que este objeto Secret está vazio. + +### Secrets de token de service account (conta de serviço) + +Secrets do tipo `kubernetes.io/service-account-token` são utilizados para +armazenar um token que identifica uma service account (conta de serviço). Ao +utilizar este tipo de Secret, você deve garantir que a anotação +`kubernetes.io/service-account.name` contém um nome de uma service account +existente. Um controlador do Kubernetes preenche outros campos, como por exemplo +a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` +com o conteúdo do token. + +O exemplo de configuração abaixo declara um Secret de token de service account: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account-name: "sa-name" +type: kubernetes.io/service-account-token +data: + # Você pode incluir pares chave-valor adicionais, da mesma forma que faria com + # Secrets do tipo Opaque + extra: YmFyCg== +``` + +Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes +automaticamente cria um Secret de service account e automaticamente atualiza o +seu Pod para utilizar este Secret. O Secret de token de service account contém +credenciais para acessar a API. + +A criação automática e o uso de credenciais de API podem ser desativados se +desejado. Porém, se tudo que você necessita é poder acessar o servidor da API +de forma segura, este é o processo recomendado. + +Veja a documentação de +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) +para mais informações sobre o funcionamento de service accounts. Você pode +verificar também os campos `automountServiceAccountToken` e `serviceAccountName` +do [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +para mais informações sobre como referenciar service accounts em Pods. + +### Secrets de configuração do Docker + +Você pode utilizar um dos tipos abaixo para criar um Secret que armazena +credenciais para accesso a um registro de contêineres compatível com Docker +para busca de imagens: +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + +O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo +`~/.dockercfg` serializado. Este arquivo é o formato legado para configuração +do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, +é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor +é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. + +O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um +conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo +`~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo +do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo +`data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo +`~/.docker/config.json` é fornecido codificado no formato base64. + +Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + +{{< note >}} +Se você não desejar fazer a codificação em formato base64, você pode utilizar o +campo `stringData` como alternativa. +{{< /note >}} + +Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor +da API verifica se a chave esperada existe no campo `data` e se o valor fornecido +pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica +se o conteúdo informado é realmente um arquivo de configuração do Docker. + +Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o +comando `kubectl` para criar um Secret de registro de contêineres compatível +com o Docker, você pode executar: +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 +``` + +Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo +conteúdo é semelhante ao exemplo abaixo: + +```json +{ + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" +} +``` + +Se você extrair o conteúdo da chave `.dockerconfigjson`, presente no campo +`data`, e decodificá-lo do formato base64, você irá obter o objeto JSON abaixo, +que é uma configuração válida do Docker criada automaticamente: + +```json +{ + "auths":{ + "my-registry:5000":{ + "username":"tiger", + "password":"pass113", + "email":"tiger@acme.com", + "auth":"dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### Secret de autenticação básica + +O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais +necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo +`data` do Secret deve conter as duas chaves abaixo: +- `username`: o usuário utilizado para autenticação; +- `password`: a senha ou token para autenticação. + +Ambos os valores para estas duas chaves são textos codificados em formato base64. +Você pode fornecer os valores como texto simples utilizando o campo `stringData` +na criação do Secret. + +O arquivo YAML abaixo é um exemplo de configuração para um Secret de autenticação +básica: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + +O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode +criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, +utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas +credenciais. O tipo embutido também fornece verificação de presença das chaves +requeridas pelo servidor da API. + +### Secret de autenticação SSH + +O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados +utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve +especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo +`stringData` com a credencial SSH a ser utilizada. + +O YAML abaixo é um exemplo de configuração para um Secret de autenticação SSH: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # os dados estão abreviados neste exemplo + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + +O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. +Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para +autenticação SSH. No entanto, a utilização do tipo embutido auxilia na +unificação dos formatos das suas credenciais e o servidor da API fornece +verificação dos campos requeridos em uma configuração de Secret. + +{{< caution >}} +Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável +entre um cliente SSH e um servidor. Uma forma secundária de estabelecer +confiança é necessária para mitigar ataques "machine-in-the-middle", como +por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. +{{< /caution >}} + +### Secrets TLS + +O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para +armazenamento de um certificado e sua chave associada que são tipicamente +utilizados para TLS. Estes dados são utilizados primariamente para a +finalização TLS do recurso Ingress, mas podem ser utilizados com outros +recursos ou diretamente por uma carga de trabalho. Ao utilizar este tipo de +Secret, as chaves `tls.key` e `tls.crt` devem ser informadas no campo `data` +(ou `stringData`) da configuração do Secret, embora o servidor da API não +valide o conteúdo de cada uma destas chaves. + +O YAML a seguir tem um exemplo de configuração para um Secret TLS: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # os dados estão abreviados neste exemplo + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + +O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um +Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou +cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a +consistência dos formatos de Secret no seu projeto; o servidor da API +valida se os campos requeridos estão presentes na configuração do Secret. + +Ao criar um Secret TLS utilizando a ferramenta de linha de comando `kubectl`, +você pode utilizar o subcomando `tls` conforme demonstrado no exemplo abaixo: +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + +O par de chaves pública/privada deve ser criado separadamente. O certificado +de chave pública a ser utilizado no argumento `--cert` deve ser codificado em +formato .PEM (formato DER codificado em texto base64) e deve corresponder à +chave privada fornecida no argumento `--key`. +A chave privada deve estar no formato de chave privada PEM não-encriptado. Em +ambos os casos, as linhas inicial e final do formato PEM (por exemplo, +`--------BEGIN CERTIFICATE-----` e `-------END CERTIFICATE----` para um +certificado) *não* são incluídas. + +### Secret de token de autoinicialização {#bootstrap-token-secrets} + +Um Secret de token de autoinicialização pode ser criado especificando o tipo de +um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo +de Secret é projetado para tokens utilizados durante o processo de inicialização +de nós. Este tipo de Secret armazena tokens utilizados para assinar ConfigMaps +conhecidos. + +Um Secret de token de autoinicialização é normalmente criado no namespace +`kube-system` e nomeado na forma `bootstrap-token-`, onde +`` é um texto com 6 caracteres contendo a identificação do token. + +No formato de manifesto do Kubernetes, um Secret de token de autoinicialização +se assemelha ao exemplo abaixo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + +Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo +`data`: +- `token-id`: Uma string com 6 caracteres aleatórios como identificador do + token. Requerido. +- `token-secret`: Uma string de 16 caracteres aleatórios como o conteúdo do + token. Requerido. +- `description`: Uma string contendo uma descrição do propósito para o qual este + token é utilizado. Opcional. +- `expiration`: Um horário absoluto UTC no formato RFC3339 especificando quando + o token deve expirar. Opcional. +- `usage-bootstrap-`: Um conjunto de flags booleanas indicando outros + usos para este token de autoinicialização. +- `auth-extra-groups`: Uma lista separada por vírgulas de nomes de grupos que + serão autenticados adicionalmente, além do grupo `system:bootstrappers`. + +O YAML acima pode parecer confuso, já que os valores estão todos codificados em +formato base64. Você pode criar o mesmo Secret utilizando este YAML: +```yaml +apiVersion: v1 +kind: Secret +metadata: + # Observe como o Secret é nomeado + name: bootstrap-token-5emitj + # Um Secret de token de inicialização geralmente fica armazenado no namespace + # kube-system + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # Esta identificação de token é utilizada no nome + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # Este token pode ser utilizado para autenticação. + usage-bootstrap-authentication: "true" + # e pode ser utilizado para assinaturas + usage-bootstrap-signing: "true" +``` + +## Criando um Secret + +Há várias formas diferentes de criar um Secret: +- [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [criar um Secret utilizando a ferramenta kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +## Editando um Secret + +Um Secret existente no cluster pode ser editado com o seguinte comando: +```shell +kubectl edit secrets mysecret +``` + +Este comando abrirá o editor padrão configurado e permitirá a modificação dos +valores codificados em base64 no campo `data`: +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Utilizando Secrets + +Secrets podem ser montados como volumes de dados ou expostos como +{{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} +para serem utilizados num container de um Pod. Secrets também podem ser +utilizados por outras partes do sistema, sem serem diretamente expostos ao Pod. +Por exemplo, Secrets podem conter credenciais que outras partes do sistema devem +utilizar para interagir com sistemas externos no lugar do usuário. + +### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} + +Para consumir um Secret em um volume em um Pod: +1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem +referenciar o mesmo secret. +1. Modifique sua definição de Pod para adicionar um volume na lista +`.spec.volumes[]`. Escolha um nome qualquer para o seu volume e adicione um +campo `.spec.volumes[].secret.secretName` com o mesmo valor do seu objeto +Secret. +1. Adicione um ponto de montagem de volume à lista +`.spec.containers[].volumeMounts[]` de cada contêiner que requer o Secret. +Especifique `.spec.containers[].volumeMounts[].readOnly = true` e especifique o +valor do campo `.spec.containers[].volumeMounts[].mountPath` com o nome de um +diretório não utilizado onde você deseja que os Secrets apareçam. +1. Modifique sua imagem ou linha de comando de modo que o programa procure por +arquivos naquele diretório. Cada chave no campo `data` se torna um nome de +arquivo no diretório especificado em `mountPath`. + +Este é um exemplo de Pod que monta um Secret em um volume: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + +Cada Secret que você deseja utilizar deve ser referenciado na lista +`.spec.volumes`. + +Se existirem múltiplos contêineres em um Pod, cada um dos contêineres necessitará +seu próprio bloco `volumeMounts`, mas somente um volume na lista `.spec.volumes` +é necessário por Secret. + +Você pode armazenar vários arquivos em um Secret ou utilizar vários Secrets +distintos, o que for mais conveniente. + +#### Projeção de chaves de Secrets a caminhos específicos + +Você pode também controlar os caminhos dentro do volume onde as chaves do Secret +são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para +mudar o caminho de destino de cada chave: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + +Neste caso: +* O valor da chave `username` é armazenado no arquivo +`/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. +* O valor da chave `password` não é projetado no sistema de arquivos. + +Se `.spec.volumes[].secret.items` for utilizado, somente chaves especificadas +na lista `items` são projetadas. Para consumir todas as chaves do Secret, deve +haver um item para cada chave no campo `items`. Todas as chaves listadas precisam +existir no Secret correspondente. Caso contrário, o volume não é criado. + +#### Permissões de arquivos de Secret + +Você pode trocar os bits de permissão de uma chave avulsa de Secret. +Se nenhuma permissão for especificada, `0644` é utilizado por padrão. +Você pode também especificar uma permissão padrão para o volume inteiro de +Secret e sobrescrever esta permissão por chave, se necessário. + +Por exemplo, você pode especificar uma permissão padrão da seguinte maneira: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + +Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados +no volume terão a permissão `0400`. + +Note que a especificação JSON não suporta notação octal. Neste caso, utilize o +valor 256 para permissões equivalentes a 0400. Se você utilizar YAML ao invés +de JSON para o Pod, você pode utilizar notação octal para especificar permissões +de uma forma mais natural. + +Perceba que se você acessar o Pod com `kubectl exec`, você precisará seguir o +vínculo simbólico para encontrar a permissão esperada. Por exemplo, + +Verifique as permissões do arquivo de Secret no pod. +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + +O resultado é semelhante ao abaixo: +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + +Siga o vínculo simbólico para encontrar a permissão correta do arquivo. +``` +cd /etc/foo/..data +ls -l +``` + +O resultado é semelhante ao abaixo: +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + +Você pode também utilizar mapeamento, como no exemplo anterior, e especificar +permissões diferentes para arquivos diferentes conforme abaixo: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + +Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as +permissões `0777`. Se você utilizar JSON, devido às limitações do formato, +você precisará informar as permissões em base decimal, ou o valor `511` neste +exemplo. + +Note que os valores de permissões podem ser exibidos em formato decimal se você +ler essa informação posteriormente. + +#### Consumindo valores de Secrets em volumes + +Dentro do contêiner que monta um volume de Secret, as chaves deste Secret +aparecem como arquivos e os valores dos Secrets são decodificados do formato +base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do +contêiner do exemplo anterior, obteremos os seguintes resultados: + +```shell +ls /etc/foo +``` + +O resultado é semelhante a: +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + +O resultado é semelhante a: +``` +admin +``` + +```shell +cat /etc/foo/password +``` + +O resultado é semelhante a: +``` +1f2d1e2e67df +``` + +A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets +dentro dos arquivos. + +#### Secrets montados são atualizados automaticamente + +Quando um Secret que está sendo consumido a partir de um volume é atualizado, as +chaves projetadas são atualizadas após algum tempo também. O kubelet verifica +se o Secret montado está atualizado a cada sincronização periódica. No entanto, +o kubelet utiliza seu cache local para buscar o valor corrente de um Secret. O +tipo do cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` +na estrutura [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). +Um Secret pode ser propagado através de um _watch_ (comportamento padrão), que +é o sistema de propagação de mudanças incrementais em objetos do Kubernetes; +baseado em TTL (_time to live_, ou tempo de expiração); ou redirecionando todas +as requisições diretamente para o servidor da API. + +Como resultado, o tempo decorrido total entre o momento em que o Secret foi +atualizado até o momento em que as novas chaves são projetadas nos Pods pode +ser tão longo quanto o tempo de sincronização do kubelet somado ao tempo de +propagação do cache, onde o tempo de propagação do cache depende do tipo de +cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação +do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. + +{{< note >}} +Um contêiner que utiliza Secrets através de um ponto de montagem com a +propriedade +[subPath](/docs/concepts/storage/volumes#using-subpath) não recebe atualizações +deste Secret. +{{< /note >}} + +### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} + +Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} +em um Pod: + +1. Crie um Secret ou utilize um já existente. Múltiplos Pods podem referenciar o +mesmo Secret. +1. Modifique a definição de cada contêiner do Pod em que desejar consumir o +Secret, adicionando uma variável de ambiente para cada uma das chaves que deseja +consumir. +A variável de ambiente que consumir o valor da chave em questão deverá popular o +nome do Secret e a sua chave correspondente no campo +`env[].valueFrom.secretKeyRef`. +1. Modifique sua imagem de contêiner ou linha de comando de forma que o programa +busque os valores nas variáveis de ambiente especificadas. + +Este é um exemplo de um Pod que utiliza Secrets em variáveis de ambiente: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### Consumindo valores de Secret em variáveis de ambiente + +Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave +do Secret aparece como uma variável de ambiente comum, contendo os dados do +Secret decodificados do formato base64. Ao executar comandos no contêiner do +exemplo anterior, obteremos os resultados abaixo: + +```shell +echo $SECRET_USERNAME +``` + +O resultado é semelhante a: + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +O resultado é semelhante a: + +``` +1f2d1e2e67df +``` + +#### Variáveis de ambiente não são atualizadas após uma atualização no Secret + +Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização +dos valores do Secret não será refletida no contêiner a menos que o contêiner +seja reiniciado. +Existem ferramentas de terceiros que oferecem reinicializações automáticas +quando Secrets são atualizados. + +## Secrets imutáveis {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma +opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters +que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens +únicas de Secrets em Pods), prevenir alterações aos dados dos Secrets traz as +seguintes vantagens: +- protege você de alterações acidentais ou indesejadas que poderiam provocar +disrupções na execução de aplicações; +- melhora a performance do seu cluster através da redução significativa de carga +no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como +imutáveis. + +Esta funcionalidade é controlada pelo +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão +v1.19. Você pode criar um Secret imutável adicionando o campo `immutable` com +o valor `true`. Por exemplo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais +possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você +pode somente apagar e recriar o Secret. Pods existentes mantém um ponto de +montagem referenciando o Secret removido - é recomendado recriar tais Pods. +{{< /note >}} + +### Usando `imagePullSecrets` {#using-imagepullsecrets} + +O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo +namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets +que contém uma senha para acesso a um registro de contêineres do Docker (ou +outros registros de contêineres) ao kubelet. O kubelet utiliza essa informação +para baixar uma imagem privada no lugar do seu Pod. +Veja a [API PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +para maiores detalhes sobre o campo `imagePullSecrets`. + +#### Especificando `imagePullSecrets` manualmente + +Você pode ler sobre como especificar `imagePullSecrets` em um Pod na +[documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). + +### Configurando `imagePullSecrets` para serem vinculados automaticamente + +Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma +ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada +explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os +mesmos valores existentes na service account. +Veja [adicionando `imagePullSecrets` a uma service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +para uma explicação detalhada do processo. + +## Detalhes + +### Restrições + +Referências a Secrets em volumes são validadas para garantir que o objeto +especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret +precisa ser criado antes de quaisquer Pods que dependam deste. + +Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Secrets podem ser referenciados somente por Pods no mesmo namespace. + +Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por +objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir +a memória do servidor da API e do kubelet. No entanto, a criação de muitos +Secrets pequenos também pode exaurir a memória. Limites mais completos de uso +de memória em função de Secrets é uma funcionalidade prevista para o futuro. + +O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos +do servidor da API. Isso inclui quaisquer Pods criados usando o comando +`kubectl`, ou indiretamente através de um controlador de replicação, mas não +inclui Pods criados como resultado das flags `--manifest-url` e `--config` do +kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). +A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} +não pode se referir a um Secret ou a qualquer outro objeto da API. + +Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de +ambiente, exceto quando são marcados como opcionais. Referências a Secrets que +não existem provocam falhas na inicialização do Pod. + +Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado +provocam falhas na inicialização do Pod. + +Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` +que contém chaves inválidas para utilização como nome de uma variável de ambiente +terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento +será gerado com a razão `InvalidVariableNames` e a mensagem gerada conterá a lista +de chaves inválidas que foram ignoradas. O exemplo abaixo demonstra um Pod que se +refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e +`2alsobad`. + +```shell +kubectl get events +``` + +O resultado é semelhante a: + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Interações do ciclo de vida entre Secrets e Pods + +Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação +da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o +kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado +porque não existe ou porque houve uma falha de comunicação temporária entre o +kubelet e o servidor da API, o kubelet fará novas tentativas periodicamente. +O kubelet irá gerar um evento sobre o Pod, explicando a razão pela qual o Pod +ainda não foi inicializado. Uma vez que o Secret tenha sido encontrado, o +kubelet irá criar e montar um volume contendo este Secret. Nenhum dos contêineres +do Pod irá iniciar até que todos os volumes estejam montados. + +## Casos de uso + +### Caso de uso: Como variáveis de ambiente em um contêiner + +Crie um manifesto de Secret + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + +Crie o Secret no seu cluster: + +```shell +kubectl apply -f mysecret.yaml +``` + +Utilize `envFrom` para definir todos os dados do Secret como variáveis de +ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de +ambiente no Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### Caso de uso: Pod com chaves SSH + +Crie um Secret contendo chaves SSH: + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + +O resultado é semelhante a: + +``` +secret "ssh-key-secret" created +``` + +Você também pode criar um manifesto `kustomization.yaml` com um campo +`secretGenerator` contendo chaves SSH. + +{{< caution >}} +Analise cuidadosamente antes de enviar suas próprias chaves SSH: outros usuários +do cluster podem ter acesso a este Secret. Utilize uma service account que você +deseje que seja acessível a todos os usuários com os quais você compartilha o +cluster do Kubernetes em questão. Desse modo, você pode revogar esta service +account caso os usuários sejam comprometidos. +{{< /caution >}} + +Agora você pode criar um Pod que referencia o Secret com a chave SSH e consome-o +em um volume: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + +O contêiner então pode utilizar os dados do secret para estabelecer uma conexão +SSH. + +### Caso de uso: Pods com credenciais de ambientes de produção ou testes + +Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um +ambiente de produção e outro Pod que consome um Secret contendo credenciais de +um ambiente de testes. + +Você pode criar um manifesto `kustomization.yaml` com um `secretGenerator` ou +rodar `kubectl create secret`. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + +O resultado é semelhante a: + +``` +secret "prod-db-secret" created +``` + +Você pode também criar um Secret com credenciais para o ambiente de testes. + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + +O resultado é semelhante a: + +``` +secret "test-db-secret" created +``` + +{{< note >}} +Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu +[shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de +sequências de escape. Na maioria dos shells, a forma mais fácil de gerar sequências +de escape para suas senhas é escrevê-las entre aspas simples (`'`). Por exemplo, +se a sua senha for `S!B\*d$zDsb=`, você deve executar o comando da seguinte +forma: + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +Não é necessário gerar sequências de escape para caracteres especiais em arquivos +(utilizados com a opção `--from-file`). +{{< /note >}} + +Agora, crie os Pods: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + +Adicione os Pods a um manifesto `kustomization.yaml`: + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Crie todos estes objetos no servidor da API rodando o comando: + +```shell +kubectl apply -k . +``` + +Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de +arquivos, com valores para cada um dos ambientes dos contêineres: + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + +Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso +facilita a criação de Pods com capacidades diferentes a partir de um template +mais genérico. + +Você pode simplificar ainda mais a definição básica do Pod através da utilização +de duas service accounts diferentes: + +1. `prod-user` com o Secret `prod-db-secret` +1. `test-user` com o Secret `test-db-secret` + +A especificação do Pod é reduzida para: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### Caso de uso: _dotfiles_ em um volume de Secret + +Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se +inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou +arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, +`secret-volume`: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner +`dotfile-test-container` terá este arquivo presente no caminho +`/etc/secret-volume/.secret-file`. + +{{< note >}} +Arquivos com nomes iniciados por um caractere de ponto são ocultos do resultado +do comando `ls -l`. Você precisa utilizar `ls -la` para vê-los ao listar o +conteúdo de um diretório. +{{< /note >}} + +### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} + +Suponha que um programa necessita manipular requisições HTTP, executar regras +de negócio complexas e então assinar mensagens com HMAC. Devido à natureza +complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos +remotos no servidor e que poderia expor a chave privada para um invasor. + +Esta aplicação poderia ser dividida em dois processos, separados em dois +contêineres distintos: um contêiner de _front-end_, que manipula as interações +com o usuário e a lógica de negócio, mas não consegue ver a chave privada; e +um contêiner assinador, que vê a chave privada e responde a requisições simples +de assinatura do _front-end_ (por exemplo, através de rede local). + +Com essa abordagem particionada, um invasor agora precisa forçar o servidor de +aplicação a rodar comandos arbitrários, o que é mais difícil de ser feito do que +apenas ler um arquivo presente no disco. + + + +## Melhores práticas + +### Clientes que utilizam a API de Secrets + +Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o +acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) +como [RBAC](/docs/reference/access-authn-authz/rbac/). + +Secrets frequentemente contém valores com um espectro de importância, muitos dos +quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service +account) e de sistemas externos. Mesmo que um aplicativo individual possa +avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro +do mesmo namespace podem tornar estas suposições inválidas. + +Por estas razões, as requisições `watch` (observar) e `list` (listar) de +Secrets dentro de um namespace são permissões extremamente poderosas e devem +ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os +valores de todos os Secrets presentes naquele namespace. A habilidade de listar +e observar todos os Secrets em um cluster deve ser reservada somente para os +componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. + +Aplicações que necessitam acessar a API de Secret devem realizar uma requisição +`get` nos Secrets que precisam. Isto permite que administradores restrinjam o +acesso a todos os Secrets, enquanto +[utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +que a aplicação precise. + +Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar +objetos que referenciam o Secret e então utilizar a requisição `watch` neste +novo objeto, requisitando o Secret novamente quando a referência mudar. +Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) +para permitir a clientes observar recursos individuais também foi proposta e +provavelmente estará disponível em versões futuras do Kubernetes. + +## Propriedades de segurança + +### Proteções + +Como Secrets podem ser criados de forma independente de Pods que os utilizam, +há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, +visualização, e edição de Pods. O sistema pode também tomar precauções adicionais +com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. + +Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet +armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret +seja escrito em armazenamento persistente. Uma vez que o Pod que depende do +Secret é removido, o kubelet apaga sua cópia local do Secret também. + +Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente +os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. +Portanto, um Pod não tem acesso aos Secrets de outro Pod. + +Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa +requerer o volume de Secret nos seus `volumeMounts` para que este fique visível +dentro do contêiner. Esta característica pode ser utilizada para construir +[partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). + +Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o +servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. +Secrets são protegidos quando transmitidos através destes canais. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + +Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) +em dados de Secret para evitar que estes sejam armazenados em texto plano no +{{< glossary_tooltip term_id="etcd" >}}. + +### Riscos + +- No servidor da API, os dados de Secret são armazenados no + {{< glossary_tooltip term_id="etcd" >}}; portanto: + - Administradores devem habilitar encriptação em disco para dados do cluster + (requer Kubernetes v1.13 ou posterior). + - Administradores devem limitar o acesso ao etcd somente para usuários + administradores. + - Administradores podem desejar apagar definitivamente ou destruir discos + previamente utilizados pelo etcd que não estiverem mais em uso. + - Ao executar o etcd em um cluster, administradores devem garantir o uso de + SSL/TLS para conexões ponto-a-ponto do etcd. +- Se você configurar um Secret utilizando um arquivo de manifesto (JSON ou + YAML) que contém os dados do Secret codificados como base64, compartilhar + este arquivo ou salvá-lo num sistema de controle de versão de código-fonte + compromete este Secret. Codificação base64 _não_ é um método de encriptação + e deve ser considerada idêntica a texto plano. +- Aplicações ainda precisam proteger o valor do Secret após lê-lo de um volume, + como por exemplo não escrever seu valor em logs ou enviá-lo para um sistema + não-confiável. +- Um usuário que consegue criar um Pod que utiliza um Secret também consegue + ler o valor daquele Secret. Mesmo que o servidor da API possua políticas para + impedir que aquele usuário leia o valor do Secret, o usuário poderia criar um + Pod que expõe o Secret. + +## {{% heading "whatsnext" %}} + +- Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Leia a [documentação de referência da API](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) de `Secrets` diff --git a/content/pt-br/docs/reference/glossary/configmap.md b/content/pt-br/docs/reference/glossary/configmap.md index a1ccdea668..4840cdb4ac 100644 --- a/content/pt-br/docs/reference/glossary/configmap.md +++ b/content/pt-br/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2021-08-24 -full_link: /docs/concepts/configuration/configmap +full_link: /pt-br/docs/concepts/configuration/configmap short_description: > Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume. diff --git a/content/pt-br/docs/reference/glossary/container-env-variables.md b/content/pt-br/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000..620dee723c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Variáveis de Ambiente de Contêineres +id: container-env-variables +date: 2021-11-20 +full_link: /pt-br/docs/concepts/containers/container-environment/ +short_description: > + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um Pod. + +aka: +tags: +- fundamental +--- + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um {{< glossary_tooltip text="pod" term_id="Pod" >}} + + + +Variáveis de ambiente de contêineres fornecem informações requeridas pela aplicação conteinerizada, junto com informações sobre recursos importantes para o {{< glossary_tooltip text="contêiner" term_id="container" >}}. Por exemplo, detalhes do sistema de arquivos, informações sobre o contêiner, e outros recursos do cluster, como endpoints de serviços. diff --git a/content/pt-br/docs/reference/glossary/container.md b/content/pt-br/docs/reference/glossary/container.md new file mode 100644 index 0000000000..7e24fa5ad7 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: Contêiner +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + Uma imagem executável leve e portável que contém software e todas as suas dependências. + +aka: +tags: +- fundamental +- workload +--- + Uma imagem executável leve e portável que contém software e todas as suas dependências. + + + +Contêineres desacoplam aplicações da infraestrutura da máquina em que estas rodam para tornar a instalação mais fácil em diferentes ambientes de nuvem e de +sistemas operacionais, e para facilitar o escalonamento das aplicações. diff --git a/content/pt-br/docs/reference/glossary/secret.md b/content/pt-br/docs/reference/glossary/secret.md index abcd1bb421..b293f7acc4 100644 --- a/content/pt-br/docs/reference/glossary/secret.md +++ b/content/pt-br/docs/reference/glossary/secret.md @@ -2,7 +2,7 @@ title: Secret id: secret date: 2021-08-24 -full_link: /docs/concepts/configuration/secret/ +full_link: /pt-br/docs/concepts/configuration/secret/ short_description: > Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH. diff --git a/content/ru/_index.html b/content/ru/_index.html index a460376f12..07d693e996 100644 --- a/content/ru/_index.html +++ b/content/ru/_index.html @@ -41,12 +41,12 @@ Kubernetes — это проект с открытым исходным кодо

- Посетите KubeCon в Северной Америке, 11-15 октября 2021 года + Посетите KubeCon в Европе, 16-20 мая 2022 года



- Посетите KubeCon в Европе, 17-20 мая 2022 года + Посетите KubeCon в Северной Америке, 24-28 октября 2022 года
diff --git a/content/uk/_index.html b/content/uk/_index.html index ebf3f6ea18..29f6941477 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -62,12 +62,12 @@ Kubernetes - проект з відкритим вихідним кодом. В

- Відвідайте KubeCon у Північній Америці, 11-15 жовтня 2021 року -
-
-
-
Відвідайте KubeCon в Європі, 17-20 травня 2022 року +
+
+
+
+ Відвідайте KubeCon у Північній Америці, 24-28 жовтня 2022 року
diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index 2a44b99e44..e7c0ab9321 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -40,6 +40,8 @@ application has to take ports as flags, the API servers have to know how to insert dynamic port numbers into configuration blocks, services have to know how to find each other, etc. Rather than deal with this, Kubernetes takes a different approach. + +To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/). --> Kubernetes 的宗旨就是在应用之间共享机器。 通常来说,共享机器需要两个应用之间不能使用相同的端口,但是在多个应用开发者之间 @@ -49,80 +51,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中,服务也需要知道如何找到对方等等。 与其去解决这些问题,Kubernetes 选择了其他不同的方法。 - -## Kubernetes 网络模型 {#the-kubernetes-network-model} - -每一个 `Pod` 都有它自己的IP地址,这就意味着你不需要显式地在每个 `Pod` 之间创建链接, -你几乎不需要处理容器端口到主机端口之间的映射。 -这将创建一个干净的、向后兼容的模型,在这个模型里,从端口分配、命名、服务发现、 -负载均衡、应用配置和迁移的角度来看,`Pod` 可以被视作虚拟机或者物理主机。 - -Kubernetes 对所有网络设施的实施,都需要满足以下的基本要求(除非有设置一些特定的网络分段策略): - -* 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 -* 节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有Pod通信 - -备注:仅针对那些支持 `Pods` 在主机网络中运行的平台(比如:Linux): - -* 那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信 - - -这个模型不仅不复杂,而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容, -如果你的工作开始是在虚拟机中运行的,你的虚拟机有一个 IP , -这样就可以和其他的虚拟机进行通信,这是基本相同的模型。 - -Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。 -这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。 -这也意味着 `Pod` 内的容器都需要相互协调端口的使用,但是这和虚拟机中的进程似乎没有什么不同, -这也被称为“一个 Pod 一个 IP”模型。 - - -如何实现这一点是正在使用的容器运行时的特定信息。 - -也可以在 `node` 本身通过端口去请求你的 `Pod`(称之为主机端口), -但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 -`Pod` 自己并不知道这些主机端口是否存在。 - +要了解 Kubernetes 网络模型,请参阅[此处](/zh/docs/concepts/services-networking/)。 -### Apstra 的 AOS - -[AOS](https://www.apstra.com/products/aos/) 是一个基于意图的网络系统, -可以通过一个简单的集成平台创建和管理复杂的数据中心环境。 -AOS 利用高度可扩展的分布式设计来消除网络中断,同时将成本降至最低。 - -AOS 参考设计当前支持三层连接的主机,这些主机消除了旧的两层连接的交换问题。 -这些三层连接的主机可以是 Linux(Debian、Ubuntu、CentOS)系统, -它们直接在机架式交换机(TOR)的顶部创建 BGP 邻居关系。 -AOS 自动执行路由邻接,然后提供对 Kubernetes 部署中常见的路由运行状况注入(RHI)的精细控制。 - -AOS 具有一组丰富的 REST API 端点,这些端点使 Kubernetes 能够根据应用程序需求快速更改网络策略。 -进一步的增强功能将用于网络设计的 AOS Graph 模型与工作负载供应集成在一起, -从而为私有云和公共云提供端到端管理系统。 - -AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备, -以及大量白盒系统和开放网络操作系统,例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux。 - -想要更详细地了解 AOS 系统是如何工作的可以点击这里:https://www.apstra.com/products/how-it-works/ - -### Big Switch Networks 的 Big Cloud Fabric - -[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) 是一个基于云原生的网络架构, -旨在在私有云或者本地环境中运行 Kubernetes。 -它使用统一的物理和虚拟 SDN,Big Cloud Fabric 解决了固有的容器网络问题, -比如负载均衡、可见性、故障排除、安全策略和容器流量监控。 - -在 Big Cloud Fabric 的虚拟 Pod 多租户架构的帮助下,容器编排系统 -(比如 Kubernetes、RedHat OpenShift、Mesosphere DC/OS 和 Docker Swarm) -将与 VM 本地编排系统(比如 VMware、OpenStack 和 Nutanix)进行本地集成。 -客户将能够安全地互联任意数量的这些集群,并且在需要时启用他们之间的租户间通信。 - -在最新的 [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html) 上, -BCF 被 Gartner 认为是非常有远见的。 -而 BCF 的一条关于 Kubernetes 的本地部署(其中包括 Kubernetes、DC/OS 和在不同地理区域的多个 -DC 上运行的 VMware)也在[这里](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)被引用。 - @@ -313,7 +183,6 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu [CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现,比如 [Flannel](https://github.com/coreos/flannel#flannel)、 [Calico](https://docs.projectcalico.org/)、 -[Romana](https://romana.io)、 [Weave-net](https://www.weave.works/products/weave-net/)。 CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multi-ip-addresses-per-pod), @@ -362,18 +231,6 @@ Coil operates with a low overhead compared to bare metal, and allows you to defi [Coil](https://github.com/cybozu-go/coil) 是一个为易于集成、提供灵活的出站流量网络而设计的 CNI 插件。 与裸机相比,Coil 的额外操作开销低,并允许针对外部网络的出站流量任意定义 NAT 网关。 - -### Contiv - -[Contiv](https://github.com/contiv/netplugin) -为各种使用情况提供了一个可配置网络(使用了 BGP 的本地 L3, -使用 vxlan 、经典 L2 或 Cisco-SDN/ACI 的覆盖网络)。 -[Contiv](https://contiv.io) 是完全开源的。 - -### Google Compute Engine (GCE) +### Hybridnet -对于 Google Compute Engine 的集群配置脚本, -[高级路由器](https://cloud.google.com/vpc/docs/routes) 用于为每个虚机分配一个子网(默认是 `/24` - 254个 IP), -绑定到该子网的任何流量都将通过 GCE 网络结构直接路由到虚机。 -这是除了分配给虚机的“主” IP 地址之外的一个补充,该 IP 地址经过 NAT 转换以用于访问外网。 -Linux 网桥(称为“cbr0”)被配置为存在于该子网中,并被传递到 Docker 的 --bridge 参数上。 - -Docker 会以这样的参数启动: - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -这个网桥是由 Kubelet(由 `--network-plugin=kubenet` 参数控制)根据节点的 `.spec.podCIDR` 参数创建的。 - -Docker 将会从 `cbr-cidr` 块分配 IP。 -容器之间可以通过 `cbr0` 网桥相互访问,也可以访问节点。 -这些 IP 都可以在 GCE 的网络中被路由。 -而 GCE 本身并不知道这些 IP,所以不会对访问外网的流量进行 NAT。 -为了实现此目的,使用了 `iptables` 规则来伪装(又称为 SNAT,使数据包看起来好像是来自“节点”本身), -将通信绑定到 GCE 项目网络(10.0.0.0/8)之外的 IP。 - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -最后,在内核中启用了 IP 转发(因此内核将处理桥接容器的数据包): - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -所有这些的结果是所有 Pod 都可以互相访问,并且可以将流量发送到互联网。 +[Hybridnet](https://github.com/alibaba/hybridnet) 是一个为混合云设计的开源 CNI 插件, +它为一个或多个集群中的容器提供覆盖和底层网络。 Overlay 和 underlay 容器可以在同一个节点上运行, +并具有集群范围的双向网络连接。 ### Multus (a Multi Network plugin) @@ -591,7 +380,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p 使用 Kubernetes 中基于 CRD 的网络对象来支持实现 Kubernetes 多网络系统。 Multus 支持所有[参考插件](https://github.com/containernetworking/plugins)(比如: -[Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)、 +[Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md)、 [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp)、 [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan) ) 来实现 CNI 规范和第三方插件(比如: @@ -623,28 +412,6 @@ NSX-T 可以为多云及多系统管理程序环境提供网络虚拟化,并 以及 NSX-T 与基于容器的 CaaS/PaaS 平台(例如 Pivotal Container Service(PKS)和 OpenShift)之间的集成。 -### Nuage Networks VCS (Virtualized Cloud Services) - -[Nuage](https://www.nuagenetworks.net) 提供了一个高度可扩展的基于策略的软件定义网络(SDN)平台。 -Nuage 使用开源的 Open vSwitch 作为数据平面,以及基于开放标准构建具有丰富功能的 SDN 控制器。 - -Nuage 平台使用覆盖层在 Kubernetes Pod 和非 Kubernetes 环境(VM 和裸机服务器)之间提供基于策略的无缝联网。 -Nuage 的策略抽象模型在设计时就考虑到了应用程序,并且可以轻松声明应用程序的细粒度策略。 -该平台的实时分析引擎可为 Kubernetes 应用程序提供可见性和安全性监控。 - - -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) 是一个较为成熟的解决方案,但同时也增加了构建覆盖网络的复杂性。 -这也得到了几个网络系统的“大商店”的拥护。 - ### OVN (开放式虚拟网络) OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。 它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。 该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。 - -### Romana - -[Romana](https://romana.io) 是一个开源网络和安全自动化解决方案。 -它可以让你在没有覆盖网络的情况下部署 Kubernetes。 -Romana 支持 Kubernetes [网络策略](/zh/docs/concepts/services-networking/network-policies/), -来提供跨网络命名空间的隔离。 - 当你部署完 Kubernetes, 即拥有了一个完整的集群。 @@ -39,9 +38,7 @@ Here's the diagram of a Kubernetes cluster with all the components tied together 本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。 -这张图表展示了包含所有相互关联组件的 Kubernetes 集群。 - -![Kubernetes 组件](/images/docs/components-of-kubernetes.svg) +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes 的组件" caption="Kubernetes 集群的组件" class="diagram-large" >}} diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 7c9fe009c3..33cf14c540 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -177,7 +177,7 @@ description: "此优先级类应仅用于 XYZ 服务 Pod。" {{< feature-state for_k8s_version="v1.19" state="beta" >}} -Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue +Pods with `preemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue, @@ -197,7 +197,7 @@ high-priority pods. {{< feature-state for_k8s_version="v1.19" state="beta" >}} -配置了 `PreemptionPolicy: Never` 的 Pod 将被放置在调度队列中较低优先级 Pod 之前, +配置了 `preemptionPolicy: Never` 的 Pod 将被放置在调度队列中较低优先级 Pod 之前, 但它们不能抢占其他 Pod。等待调度的非抢占式 Pod 将留在调度队列中,直到有足够的可用资源, 它才可以被调度。非抢占式 Pod,像其他 Pod 一样,受调度程序回退的影响。 这意味着如果调度程序尝试这些 Pod 并且无法调度它们,它们将以更低的频率被重试, @@ -206,26 +206,26 @@ high-priority pods. 非抢占式 Pod 仍可能被其他高优先级 Pod 抢占。 -`PreemptionPolicy` 默认为 `PreemptLowerPriority`, +`preemptionPolicy` 默认为 `PreemptLowerPriority`, 这将允许该 PriorityClass 的 Pod 抢占较低优先级的 Pod(现有默认行为也是如此)。 -如果 `PreemptionPolicy` 设置为 `Never`,则该 PriorityClass 中的 Pod 将是非抢占式的。 +如果 `preemptionPolicy` 设置为 `Never`,则该 PriorityClass 中的 Pod 将是非抢占式的。 数据科学工作负载是一个示例用例。用户可以提交他们希望优先于其他工作负载的作业, 但不希望因为抢占运行中的 Pod 而导致现有工作被丢弃。 -设置为 `PreemptionPolicy: Never` 的高优先级作业将在其他排队的 Pod 之前被调度, +设置为 `preemptionPolicy: Never` 的高优先级作业将在其他排队的 Pod 之前被调度, 只要足够的集群资源“自然地”变得可用。 @@ -664,4 +664,4 @@ kubelet 使用优先级来确定 [默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) * 了解 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) * 了解 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) -* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) \ No newline at end of file +* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) diff --git a/content/zh/docs/contribute/participate/roles-and-responsibilities.md b/content/zh/docs/contribute/participate/roles-and-responsibilities.md index 2b91550a60..7739af7584 100644 --- a/content/zh/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/zh/docs/contribute/participate/roles-and-responsibilities.md @@ -269,7 +269,7 @@ To apply: 1. 发起 PR,将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 文件的特定节。 {{< note >}} @@ -383,7 +383,7 @@ When you meet the [requirements](https://github.com/kubernetes/community/blob/ma -1. 确认没有特权 Pod 执行 docker 命令。 -2. 检查 Kubernetes 基础架构外部节点上的脚本和应用,确认它们没有执行 Docker 命令。可能的命令有: +--> +1. 确认没有特权 Pod 执行 Docker 命令(如 `docker ps`)、重新启动 Docker + 服务(如 `systemctl restart docker.service`)或修改 + Docker 配置文件 `/etc/docker/daemon.json`。 +2. 检查 Docker 配置文件(如 `/etc/docker/daemon.json`)中容器镜像仓库的镜像(mirror)站点设置。 + 这些配置通常需要针对不同容器运行时来重新设置。 +3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行Docker命令。 + 可能的情况如: - SSH 到节点排查故障; - 节点启动脚本; - - 直接安装在节点上的监视和安全代理。 -3. 检查执行了上述特权操作的第三方工具。详细操作请参考: - [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) -4. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况,不太可能影响你的应用。 + - 直接安装在节点上的监控和安全代理。 +4. 检查执行上述特权操作的第三方工具。详细操作请参考: + [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) +5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况,不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性,比如,基于特定指标发警报,或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具,需要在迁移之前,在测试集群上完成功能验证。 - diff --git a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md new file mode 100644 index 0000000000..7a6f3c8df9 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -0,0 +1,83 @@ +--- +title: 查明节点上所使用的容器运行时 +content_type: task +weight: 10 +--- + + + + + +本页面描述查明集群中节点所使用的[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) +的步骤。 + + +取决于你运行集群的方式,节点所使用的容器运行时可能是事先配置好的, +也可能需要你来配置。如果你在使用托管的 Kubernetes 服务, +可能存在特定于厂商的方法来检查节点上配置的容器运行时。 +本页描述的方法应该在能够执行 `kubectl` 的场合下都可以工作。 + +## {{% heading "prerequisites" %}} + + +安装并配置 `kubectl`。参见[安装工具](/zh/docs/tasks/tools/#kubectl) 节了解详情。 + + +## 查明节点所使用的容器运行时 + +使用 `kubectl` 来读取并显示节点信息: + +```shell +kubectl get nodes -o wide +``` + + +输出如下面所示。`CONTAINER-RUNTIME` 列给出容器运行时及其版本。 + +```none +# For dockershim +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.16.15 docker://19.3.1 +node-2 Ready v1.16.15 docker://19.3.1 +node-3 Ready v1.16.15 docker://19.3.1 +``` + +```none +# For containerd +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.19.6 containerd://1.4.1 +node-2 Ready v1.19.6 containerd://1.4.1 +node-3 Ready v1.19.6 containerd://1.4.1 +``` + + +你可以在[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) +页面找到与容器运行时相关的更多信息。 + diff --git a/content/zh/docs/tutorials/security/_index.md b/content/zh/docs/tutorials/security/_index.md new file mode 100644 index 0000000000..0b95f9304e --- /dev/null +++ b/content/zh/docs/tutorials/security/_index.md @@ -0,0 +1,5 @@ +--- +title: "安全" +weight: 40 +--- + diff --git a/content/zh/docs/tutorials/security/cluster-level-pss.md b/content/zh/docs/tutorials/security/cluster-level-pss.md new file mode 100644 index 0000000000..0b4721c43b --- /dev/null +++ b/content/zh/docs/tutorials/security/cluster-level-pss.md @@ -0,0 +1,444 @@ +--- +title: 在集群级别应用 Pod 安全标准 +content_type: tutorial +weight: 10 +--- + + +{{% alert title="Note" %}} + +本教程仅适用于新集群。 +{{% /alert %}} + + +Pod 安全准入(PSA)在 v1.23 及更高版本默认启用, +因为它[升级到测试版(beta)](/blog/2021/12/09/pod-security-admission-beta/)。 +Pod 安全准入是在创建 Pod 时应用 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)的准入控制器。 +本教程将向你展示如何在集群级别实施 `baseline` Pod 安全标准, +该标准将标准配置应用于集群中的所有名称空间。 + +要将 Pod 安全标准应用于特定名字空间, +请参阅[在名字空间级别应用 Pod 安全标准](/zh/docs/tutorials/security/ns-level-pss)。 + +## {{% heading "prerequisites" %}} + +在你的工作站中安装以下内容: + +- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + + +## 正确选择要应用的 Pod 安全标准 {#choose-the-right-pod-security-standard-to-apply} + +[Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +允许你使用以下模式应用内置的 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/): +`enforce`、`audit` 和 `warn`。 + +要收集信息以便选择最适合你的配置的 Pod 安全标准,请执行以下操作: + + +1. 创建一个没有应用 Pod 安全标准的集群: + + ```shell + kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 + ``` + + 输出类似于: + ``` + Creating cluster "psa-wo-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-wo-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-wo-cluster-pss + + Thanks for using kind! 😊 + + ``` + + +2. 将 kubectl 上下文设置为新集群: + + ```shell + kubectl cluster-info --context kind-psa-wo-cluster-pss + ``` + + 输出类似于: + + ``` + Kubernetes control plane is running at https://127.0.0.1:61350 + CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +3. 获取集群中的名字空间列表: + + ```shell + kubectl get ns + ``` + + 输出类似于: + ``` + NAME STATUS AGE + default Active 9m30s + kube-node-lease Active 9m32s + kube-public Active 9m32s + kube-system Active 9m32s + local-path-storage Active 9m26s + ``` + + +4. 使用 `--dry-run=server` 来了解应用不同的 Pod 安全标准时会发生什么: + + 1. Privileged + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=privileged + ``` + + 输出类似于: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + 2. Baseline + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=baseline + ``` + + 输出类似于: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest" + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + + 3. Restricted + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=restricted + ``` + + 输出类似于: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest" + Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + namespace/kube-system labeled + Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest" + Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile + namespace/local-path-storage labeled + ``` + + +从前面的输出中,你会注意到应用 `privileged` Pod 安全标准不会显示任何名字空间的警告。 +然而,`baseline` 和 `restricted` 标准都有警告,特别是在 `kube-system` 名字空间中。 + + +## 设置模式、版本和标准 {#set-modes-versions-and-standards} + +在本节中,你将以下 Pod 安全标准应用于最新(`latest`)版本: + +* 在 `enforce` 模式下的 `baseline` 标准。 +* `warn` 和 `audit` 模式下的 `restricted` 标准。 + + +`baseline` Pod 安全标准提供了一个方便的中间立场,能够保持豁免列表简短并防止已知的特权升级。 + +此外,为了防止 `kube-system` 中的 Pod 失败,你将免除该名字空间应用 Pod 安全标准。 + +在你自己的环境中实施 Pod 安全准入时,请考虑以下事项: + + +1. 根据应用于集群的风险状况,更严格的 Pod 安全标准(如 `restricted`)可能是更好的选择。 +2. 对 `kube-system` 名字空间进行赦免会允许 Pod 在其中以 `privileged` 模式运行。 + 对于实际使用,Kubernetes 项目强烈建议你应用严格的 RBAC 策略来限制对 `kube-system` 的访问, + 遵循最小特权原则。 +3. 创建一个配置文件,Pod 安全准入控制器可以使用该文件来实现这些 Pod 安全标准: + + ``` + mkdir -p /tmp/pss + cat < /tmp/pss/cluster-level-pss.yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: AdmissionConfiguration + plugins: + - name: PodSecurity + configuration: + apiVersion: pod-security.admission.config.k8s.io/v1beta1 + kind: PodSecurityConfiguration + defaults: + enforce: "baseline" + enforce-version: "latest" + audit: "restricted" + audit-version: "latest" + warn: "restricted" + warn-version: "latest" + exemptions: + usernames: [] + runtimeClasses: [] + namespaces: [kube-system] + EOF + ``` + + +4. 在创建集群时配置 API 服务器使用此文件: + + ``` + cat < /tmp/pss/cluster-config.yaml + kind: Cluster + apiVersion: kind.x-k8s.io/v1alpha4 + nodes: + - role: control-plane + kubeadmConfigPatches: + - | + kind: ClusterConfiguration + apiServer: + extraArgs: + admission-control-config-file: /etc/config/cluster-level-pss.yaml + extraVolumes: + - name: accf + hostPath: /etc/config + mountPath: /etc/config + readOnly: false + pathType: "DirectoryOrCreate" + extraMounts: + - hostPath: /tmp/pss + containerPath: /etc/config + # optional: if set, the mount is read-only. + # default false + readOnly: false + # optional: if set, the mount needs SELinux relabeling. + # default false + selinuxRelabel: false + # optional: set propagation mode (None, HostToContainer or Bidirectional) + # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation + # default None + propagation: None + EOF + ``` + + {{}} + + 如果你在 macOS 上使用 Docker Desktop 和 KinD, + 你可以在菜单项 **Preferences > Resources > File Sharing** + 下添加 `/tmp` 作为共享目录。 + {{}} + + +5. 创建一个使用 Pod 安全准入的集群来应用这些 Pod 安全标准: + + ```shell + kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml + ``` + + 输出类似于: + ``` + Creating cluster "psa-with-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-with-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-with-cluster-pss + + Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 + ``` + + +6. 将 kubectl 指向集群 + + ```shell + kubectl cluster-info --context kind-psa-with-cluster-pss + ``` + + 输出类似于: + ``` + Kubernetes control plane is running at https://127.0.0.1:63855 + CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +7. 创建以下 Pod 规约作为在 default 名字空间中的一个最小配置: + + ``` + cat < /tmp/pss/nginx-pod.yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 + EOF + ``` + + +8. 在集群中创建 Pod: + + ```shell + kubectl apply -f /tmp/pss/nginx-pod.yaml + ``` + + 输出类似于: + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + + +## 清理 {#clean-up} + +运行 `kind delete cluster -name psa-with-cluster-pss` 和 +`kind delete cluster -name psa-wo-cluster-pss` 来删除你创建的集群。 + +## {{% heading "whatsnext" %}} + + +- 运行一个 [shell 脚本](/zh/examples/security/kind-with-cluster-level-baseline-pod-security.sh) + 一次执行前面的所有步骤: + 1. 创建一个基于 Pod 安全标准的集群级别配置 + 2. 创建一个文件让 API 服务器消费这个配置 + 3. 创建一个集群,用这个配置创建一个 API 服务器 + 4. 设置 kubectl 上下文为这个新集群 + 5. 创建一个最小的 Pod yaml 文件 + 6. 应用这个文件,在新集群中创建一个 Pod +- [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +- [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) +- [在名字空间级别应用 Pod 安全标准](/zh/docs/tutorials/security/ns-level-pss/) \ No newline at end of file diff --git a/content/zh/docs/tutorials/security/ns-level-pss.md b/content/zh/docs/tutorials/security/ns-level-pss.md new file mode 100644 index 0000000000..5b579dfc28 --- /dev/null +++ b/content/zh/docs/tutorials/security/ns-level-pss.md @@ -0,0 +1,243 @@ +--- +title: 在名字空间级别应用 Pod 安全标准 +content_type: tutorial +weight: 10 +--- + + + +{{% alert title="Note" %}} + +本教程仅适用于新集群。 +{{% /alert %}} + + +Pod 安全准入(PSA)在 v1.23 及更高版本默认启用, +因为它[升级到测试版(beta)](/blog/2021/12/09/pod-security-admission-beta/)。 +Pod 安全准入是在创建 Pod 时应用 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)的准入控制器。 +在本教程中,你将应用 `baseline` Pod 安全标准,每次一个名字空间。 + +你还可以在集群级别一次将 Pod 安全标准应用于多个名称空间。 +有关说明,请参阅[在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss)。 + +## {{% heading "prerequisites" %}} + + +在你的工作站中安装以下内容: + +- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + + +## 创建集群 {#create-cluster} + +2. 按照如下方式创建一个 `KinD` 集群: + + ```shell + kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 + ``` + + 输出类似于: + ``` + Creating cluster "psa-ns-level" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-ns-level" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-ns-level + + Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ + ``` + + +1. 将 kubectl 上下文设置为新集群: + ```shell + kubectl cluster-info --context kind-psa-ns-level + ``` + + 输出类似于: + ``` + Kubernetes control plane is running at https://127.0.0.1:50996 + CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +## 创建名字空间 {#create-a-namespace} + +创建一个名为 `example` 的新名字空间: + +```shell +kubectl create ns example +``` + +输出类似于: +``` +namespace/example created +``` + + +## 应用 Pod 安全标准 {#apply-pod-security-standards} + +1. 使用内置 Pod 安全准入所支持的标签在此名字空间上启用 Pod 安全标准。 + 在这一步中,我们将根据最新版本(默认值)对基线 Pod 安全标准发出警告。 + + ```shell + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/warn=baseline \ + pod-security.kubernetes.io/warn-version=latest + ``` + + +2. 可以使用标签在任何名字空间上启用多个 Pod 安全标准。 + 以下命令将强制(`enforce`) 执行基线(`baseline`)Pod 安全标准, + 但根据最新版本(默认值)对受限(`restricted`)Pod 安全标准执行警告(`warn`)和审核(`audit`)。 + + ``` + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/enforce=baseline \ + pod-security.kubernetes.io/enforce-version=latest \ + pod-security.kubernetes.io/warn=restricted \ + pod-security.kubernetes.io/warn-version=latest \ + pod-security.kubernetes.io/audit=restricted \ + pod-security.kubernetes.io/audit-version=latest + ``` + + +## 验证 Pod 安全标准 {#verify-the-pod-security-standards} + +1. 在 `example` 名字空间中创建一个最小的 pod: + + ```shell + cat < /tmp/pss/nginx-pod.yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 + EOF + ``` + + +1. 将 Pod 规约应用到集群中的 `example` 名字空间中: + ```shell + kubectl apply -n example -f /tmp/pss/nginx-pod.yaml + ``` + + 输出类似于: + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + + +3. 将 Pod 规约应用到集群中的 `default` 名字空间中: + ```shell + kubectl apply -n default -f /tmp/pss/nginx-pod.yaml + ``` + + 输出类似于: + ``` + pod/nginx created + ``` + + +以上 Pod 安全标准仅被应用到 `example` 名字空间。 +你可以在没有警告的情况下在 `default` 名字空间中创建相同的 Pod。 + + +## 清理 {#clean-up} + +运行 `kind delete cluster -name psa-ns-level` 删除创建的集群。 + +## {{% heading "whatsnext" %}} + + +- 运行一个 [shell 脚本](/examples/security/kind-with-namespace-level-baseline-pod-security.sh) + 一次执行所有前面的步骤。 + 1. 创建 KinD 集群 + 2. 创建新的名字空间 + 3. 在 `enforce` 模式下应用 `baseline` Pod 安全标准, + 同时在 `warn` 和 `audit` 模式下应用 `restricted` Pod 安全标准。 + 4. 创建一个应用以下 Pod 安全标准的新 Pod +- [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +- [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) +- [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/) diff --git a/content/zh/includes/task-tutorial-prereqs.md b/content/zh/includes/task-tutorial-prereqs.md index 822c01fe19..49d28ea552 100644 --- a/content/zh/includes/task-tutorial-prereqs.md +++ b/content/zh/includes/task-tutorial-prereqs.md @@ -1,11 +1,12 @@ 你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 -如果你还没有集群,你可以通过 [Minikube](/zh/docs/tasks/tools/#minikube) 构建一 -个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建: +建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 +如果你还没有集群,你可以通过 [Minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) +构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建: diff --git a/data/i18n/ja/ja.toml b/data/i18n/ja/ja.toml index a7a103f435..3fdeebe8d2 100644 --- a/data/i18n/ja/ja.toml +++ b/data/i18n/ja/ja.toml @@ -184,6 +184,12 @@ other = "購読する" [ui_search_placeholder] other = "検索" +[thirdparty_message] +other = """このセクションでは、Kubernetesが必要とする機能を提供するサードパーティープロジェクトにリンクしています。これらのプロジェクトはアルファベット順に記載されていて、Kubernetesプロジェクトの作者は責任を持ちません。このリストにプロジェクトを追加するには、変更を提出する前にcontent guideをお読みください。詳細はこちら。""" + +[thirdparty_message_disclaimer] +other = """

このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、CNCFウェブサイトのガイドラインをご覧ください。第三者のリンクを追加するような変更を提案する前に、コンテンツガイドを読むべきです。

""" + [version_check_mustbe] other = "作業するKubernetesサーバーは次のバージョンである必要があります: " diff --git a/static/_redirects b/static/_redirects index 780597c901..10e81668ee 100644 --- a/static/_redirects +++ b/static/_redirects @@ -335,6 +335,8 @@ /docs/tutorials/kubernetes-basics/expose-intro/ /docs/tutorials/kubernetes-basics/expose/expose-intro/ 301 /docs/tutorials/kubernetes-basics/scale-interactive/ /docs/tutorials/kubernetes-basics/scale/scale-interactive/ 301 /docs/tutorials/kubernetes-basics/scale-intro/ /docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 +/docs/tutorials/clusters/apparmor/ /docs/tutorials/security/apparmor/ 301 +/docs/tutorials/clusters/seccomp/ /docs/tutorials/security/seccomp/ 301 /ja/docs/tutorials/kubernetes-basics/scale-intro/ /ja/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /ko/docs/tutorials/kubernetes-basics/scale-intro/ /ko/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /docs/tutorials/kubernetes-basics/update-interactive/ /docs/tutorials/kubernetes-basics/update/update-interactive/ 301