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

Merge pull request #45895 from drewhagen/merged-main-dev-1.30 

Merge main branch into dev-1.30 one last time
pull/44710/head
Drew Hagen 2024-04-16 19:19:23 -05:00 committed by GitHub
parent ac8ab4588d 4c6ba12390
commit 344254b07f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
94 changed files with 2080 additions and 790 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README-es.md
View File

@ -1,6 +1,6 @@
# La documentación de Kubernetes
[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys)
[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
Bienvenido!

46
README-vi.md
View File

@ -4,14 +4,14 @@
Kho lưu trữ này chứa các tài sản cần thiết để xây dựng [trang web và tài liệu Kubernetes](https://kubernetes.io/). Chúng tôi rất vui mừng khi bạn muốn đóng góp!
- [Đóng góp vào tài liệu](#contributing-to-the-docs)
- [READMEs địa phương](#localization-readmes)
- [Đóng góp vào tài liệu](#đóng-góp-vào-tài-liệu)
- [READMEs đa ngôn ngữ](#các-tệp-readme-đa-ngôn-ngữ)
## Sử dụng kho lưu trữ này
Bạn có thể chạy trang web này ở chế độ local bằng cách sử dụng [Hugo (Phiên bản mở rộng)](https://gohugo.io/), hoặc bạn có thể chạy nó trong một container runtime. Chúng tôi mạnh mẽ khuyến nghị sử dụng container runtime, vì nó mang lại tính nhất quán trong triển khai với trang web thực tế.
Bạn có thể chạy trang web này ở chế độ local bằng cách sử dụng [Hugo (Phiên bản mở rộng)](https://gohugo.io/), hoặc bạn có thể chạy nó trong một container runtime. Chúng tôi khuyến nghị sử dụng container runtime, vì nó mang lại tính nhất quán trong triển khai so với trang web thực tế.
## Yêu cầu tiên quyết
## Chuẩn bị để sử dụng
Để sử dụng kho lưu trữ này, bạn cần cài đặt các phần mềm sau trên máy tính của bạn:
@ -20,6 +20,9 @@ Bạn có thể chạy trang web này ở chế độ local bằng cách sử d
- [Hugo (Phiên bản mở rộng)](https://gohugo.io/)
- Một container runtime, như [Docker](https://www.docker.com/).
> [!Chú ý]
Hãy chắc chắn rằng bạn mở rộng của Hugo bạn cài đặt trùng với phiên bản được chỉ định thông qua biến môi trường `HUGO_VERSION` trong tệp [`netlify.toml`](netlify.toml#L11).
Trước khi bắt đầu, hãy cài đặt các phụ thuộc. Sao chép kho lưu trữ và di chuyển đến thư mục:
```bash
@ -27,7 +30,7 @@ git clone https://github.com/kubernetes/website.git
cd website
```
Trang web Kubernetes sử dụng [chủ đề Docsy Hugo](https://github.com/google/docsy#readme). Ngay cả khi bạn dự định chạy trang web trong một vùng chứa, chúng tôi thực sự khuyên bạn nên kéo mô-đun con và các phần phụ thuộc phát triển khác bằng cách chạy như sau:
Trang web Kubernetes sử dụng [Docsy Hugo](https://github.com/google/docsy#readme). Ngay cả khi bạn dự định chạy trang web trong một vùng chứa, chúng tôi thực sự khuyên bạn nên kéo mô-đun con và các phần phụ thuộc phát triển khác bằng cách chạy như sau:
### Windows
@ -52,13 +55,13 @@ make module-init
make container-serve
```
Nếu bạn thấy lỗi, điều đó có thể có nghĩa là container Hugo không có đủ tài nguyên điện toán. Để giải quyết nó, hãy tăng số lượng sử dụng CPU và bộ nhớ được phép cho Docker trên máy của bạn ([macOS] (<https://docs.docker.com/desktop/setings/mac/>) và [windows] (https: // tài liệu .Docker.com/Desktop/Cài đặt/Windows/)).
Nếu bạn thấy lỗi, điều đó có thể có nghĩa là container Hugo không có đủ tài nguyên. Để giải quyết nó, hãy tăng số lượng CPU và bộ nhớ được phép sử dụng cho Docker trên máy của bạn ([macOS](https://docs.docker.com/desktop/setings/mac/) và [windows](https://docs.docker.com/desktop/settings/windows/)).
Mở trình duyệt của bạn để <http://localhost:1313> để xem trang web. Khi bạn thay đổi các tệp nguồn, Hugo cập nhật trang web và buộc phải làm mới trình duyệt.
Mở trình duyệt của bạn, truy cập <http://localhost:1313> để xem trang web. Khi bạn thay đổi các tệp nguồn, Hugo sẽ cập nhật và tự động làm mới lại trang web.
## Chạy trang web cục bộ bằng cách sử dụng Hugo
## Chạy trang web trực tiếp bằng cách sử dụng Hugo
Đảm bảo cài đặt phiên bản mở rộng Hugo được chỉ định bởi biến môi trường `Hugo_version` trong tệp [`netlify.toml`] (netlify.toml#l11).
Đảm bảo cài đặt phiên bản mở rộng Hugo được chỉ định bởi biến môi trường `HUGO_VERSION` trong tệp [`netlify.toml`](netlify.toml#l11).
Để cài đặt các phụ thuộc, triển khai và kiểm tra trang web cục bộ, chạy:
@ -76,11 +79,11 @@ Mở trình duyệt của bạn để <http://localhost:1313> để xem trang we
hugo.exe server --buildFuture --environment development
```
Điều này sẽ khởi động máy chủ Hugo cục bộ trên cổng 1313. Mở trình duyệt của bạn thành <http://localhost:1313> để xem trang web. Khi bạn thay đổi các tệp nguồn, Hugo cập nhật trang web và buộc phải làm mới trình duyệt.
Máy chủ Hugo cục bộ sẽ được khởi động trên cổng 1313. Mở trình duyệt của bạn, truy cập <http://localhost:1313> để xem trang web. Khi bạn thay đổi các tệp nguồn, Hugo sẽ cập nhật và tự động làm mới lại trang web.
## Xây dựng các trang tài liệu tham khảo API
Các trang tài liệu tham khảo API nằm trong `content/en/docs/reference/kubernetes-api` được xây dựng từ Swagger specification, còn được gọi là OpenAPI specification, sử dụng <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.
Các trang tài liệu tham khảo API nằm trong thư mục `content/en/docs/reference/kubernetes-api` được xây dựng từ Swagger specification, còn được gọi là OpenAPI specification, sử dụng <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.
Để cập nhật các trang tài liệu tham khảo cho một phiên bản Kubernetes mới, làm theo các bước sau:
@ -104,7 +107,7 @@ Các trang tài liệu tham khảo API nằm trong `content/en/docs/reference/ku
make api-reference
```
Bạn có thể kiểm tra kết quả trên máy cục bộ bằng cách xây dựng và chạy trang web từ một container:
Bạn có thể kiểm tra kết quả bằng cách xây dựng và chạy trang web từ một container:
```bash
make container-serve
@ -112,13 +115,14 @@ Các trang tài liệu tham khảo API nằm trong `content/en/docs/reference/ku
Trong trình duyệt web, truy cập vào <http://localhost:1313/docs/reference/kubernetes-api/> để xem tài liệu tham khảo API.
5. Khi tất cả các thay đổi của hợp đồng mới được phản ánh vào các tệp cấu hình `toc.yaml` và `fields.yaml`, tạo một Pull Request với các trang tài liệu tham khảo API mới được tạo ra.
5. Khi tất cả các thay đổi được phản ánh vào các tệp cấu hình `toc.yaml` và `fields.yaml`, tạo một Pull Request với các trang tài liệu tham khảo API mới được tạo ra.
## Khắc phục sự cố
### Lỗi: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): tính năng này không khả dụng trong phiên bản Hugo hiện tại của bạn
### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
Hugo được cung cấp dưới dạng hai bộ công cụ nhị phân vì lý do kỹ thuật. Trang web hiện tại chạy dựa trên phiên bản **Hugo Extended** duy nhất. Trong [trang phát hành](https://github.com/gohugoio/hugo/releases), tìm kiếm các bản lưu trữ có chứa từ khóa `extended` trong tên. Để xác nhận, chạy `hugo version` và tìm từ khóa `extended`.
Hugo được cung cấp dưới dạng hai phiên bản (cơ bản và bản mở rộng - extended) vì lý do kỹ thuật. Trang web hiện tại chỉ chạy với phiên bản **Hugo Extended**. Trong [trang phát hành của Hugo](https://github.com/gohugoio/hugo/releases), tìm kiếm các
phiên bản có chứa từ khóa `extended` trong tên. Để xác nhận, chạy `hugo version` và tìm từ khóa `extended`.
### Khắc phục sự cố trên macOS với quá nhiều tệp mở
@ -133,12 +137,12 @@ Hãy kiểm tra giới hạn hiện tại cho số tệp mở:
`launchctl limit maxfiles`
Sau đó, chạy các lệnh sau (được thích nghi từ <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>):
Sau đó, chạy các lệnh sau (được lấy từ <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>):
```shell
#!/bin/sh
# Đây là các liên kết gist gốc, liên kết đến các gist của tôi ngay bây giờ.
# These are the original gist links, linking to my gists now.
# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
@ -154,7 +158,7 @@ sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
```
Điều này hoạt động cho cả macOS Catalina và Mojave.
Các lệnh trên hoạt động trên cả macOS Catalina và Mojave.
## Tham gia với SIG Docs
@ -163,14 +167,14 @@ Tìm hiểu thêm về cộng đồng SIG Docs Kubernetes và cuộc họp trên
Bạn cũng có thể liên hệ với những người duy trì dự án này tại:
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
- [Nhận lời mời tham gia Slack này](https://slack.k8s.io/)
- [Nhận lời mời tham gia Slack này](https://slack.k8s.io/)
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
## Đóng góp vào tài liệu
Bạn có thể nhấp vào nút **Fork** ở phía trên bên phải của màn hình để tạo một bản sao của kho lưu trữ này trong tài khoản GitHub của bạn. Bản sao này được gọi là _fork_. Thực hiện bất kỳ thay đổi nào bạn muốn trong fork của bạn, và khi bạn sẵn sàng gửi những thay đổi đó cho chúng tôi, hãy vào fork của bạn và tạo một pull request mới để thông báo cho chúng tôi biết về nó.
Sau khi pull request của bạn được tạo, một người xem Kubernetes sẽ chịu trách nhiệm cung cấp phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi pull request của mình để giải quyết phản hồi đã được cung cấp cho bạn bởi người xem Kubernetes.**
Sau khi pull request của bạn được tạo, một người xem Kubernetes sẽ chịu trách nhiệm cung cấp phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi pull request của mình để giải quyết phản hồi đã được cung cấp cho bạn bởi người đánh giá tài liệu Kubernetes.**
Lưu ý rằng bạn có thể nhận được phản hồi từ nhiều người đánh giá Kubernetes hoặc bạn có thể nhận được phản hồi từ một người đánh giá Kubernetes khác với người được chỉ định ban đầu để cung cấp phản hồi.
@ -210,4 +214,4 @@ Sự tham gia vào cộng đồng Kubernetes được điều chỉnh bởi [Quy
## Cảm ơn bạn
Kubernetes phát triển dựa trên sự tham gia của cộng đồng, và chúng tôi đánh giá cao những đóng góp của bạn cho trang web và tài liệu của chúng tôi!
Kubernetes phát triển dựa trên sự tham gia của cộng đồng, và chúng tôi đánh giá cao những đóng góp của bạn cho trang web và tài liệu của chúng tôi!

4
content/en/blog/_index.md
View File

@ -4,9 +4,7 @@ linkTitle: Blog
menu:
main:
title: "Blog"
weight: 40
post: >
<p>Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.</p>
weight: 20
---
{{< comment >}}

4
content/en/blog/_posts/2024-01-15-SIG-Release-Spotlight/index.md
View File

@ -4,10 +4,10 @@ title: "Spotlight on SIG Release (Release Team Subproject)"
date: 2024-01-15
slug: sig-release-spotlight-2023
canonicalUrl: https://www.kubernetes.dev/blog/2024/01/15/sig-release-spotlight-2023/
author: >
Nitish Kumar
---
**Author:** Nitish Kumar
The Release Special Interest Group (SIG Release), where Kubernetes sharpens its blade
with cutting-edge features and bug fixes every 4 months. Have you ever considered how such a big
project like Kubernetes manages its timeline so efficiently to release its new version, or how

4
content/en/blog/_posts/2024-01-23-image-filesystem.md
View File

@ -3,10 +3,10 @@ layout: blog
title: 'Image Filesystem: Configuring Kubernetes to store containers on a separate filesystem'
date: 2024-01-23
slug: kubernetes-separate-image-filesystem
author: >
Kevin Hannon (Red Hat)
---
**Author:** Kevin Hannon (Red Hat)
A common issue in running/operating Kubernetes clusters is running out of disk space.
When the node is provisioned, you should aim to have a good amount of storage space for your container images and running containers.
The [container runtime](/docs/setup/production-environment/container-runtimes/) usually writes to `/var`.

4
content/en/blog/_posts/2024-02-22-k8s-book-club/index.md
View File

@ -4,10 +4,10 @@ title: "A look into the Kubernetes Book Club"
slug: k8s-book-club
date: 2024-02-22
canonicalUrl: https://www.k8s.dev/blog/2024/02/22/k8s-book-club/
author: >
Frederico Muñoz (SAS Institute)
---
**Author**: Frederico Muñoz (SAS Institute)
Learning Kubernetes and the entire ecosystem of technologies around it is not without its
challenges. In this interview, we will talk with [Carlos Santana
(AWS)](https://www.linkedin.com/in/csantanapr/) to learn a bit more about how he created the

4
content/en/blog/_posts/2024-03-01-sig-cloud-provider-spotlight.md
View File

@ -4,10 +4,10 @@ title: "Spotlight on SIG Cloud Provider"
slug: sig-cloud-provider-spotlight-2024
date: 2024-03-01
canonicalUrl: https://www.k8s.dev/blog/2024/03/01/sig-cloud-provider-spotlight-2024/
author: >
Arujjwal Negi
---
**Author**: Arujjwal Negi
One of the most popular ways developers use Kubernetes-related services is via cloud providers, but
have you ever wondered how cloud providers can do that? How does this whole process of integration
of Kubernetes to various cloud providers happen? To answer that, let's put the spotlight on [SIG

4
content/en/blog/_posts/2024-03-07-cri-o-seccomp-oci-artifacts.md
View File

@ -3,10 +3,10 @@ layout: blog
title: "CRI-O: Applying seccomp profiles from OCI registries"
date: 2024-03-07
slug: cri-o-seccomp-oci-artifacts
author: >
Sascha Grunert
---
**Author:** Sascha Grunert
Seccomp stands for secure computing mode and has been a feature of the Linux
kernel since version 2.6.12. It can be used to sandbox the privileges of a
process, restricting the calls it is able to make from userspace into the

8
content/en/blog/_posts/2024-03-12-mid-cycle-1.30.md
View File

@ -3,10 +3,14 @@ layout: blog
title: 'A Peek at Kubernetes v1.30'
date: 2024-03-12
slug: kubernetes-1-30-upcoming-changes
author: >
Amit Dsouza,
Frederick Kautz,
Kristin Martin,
Abigail McCarthy,
Natali Vlatko
---
**Authors:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko
## A quick look: exciting changes in Kubernetes v1.30
It's a new year and a new Kubernetes release. We're halfway through the release cycle and

7
content/en/blog/_posts/2024-04-03-windows-ops-readiness.md
View File

@ -3,11 +3,12 @@ layout: blog
title: "Introducing the Windows Operational Readiness Specification"
date: 2024-04-03
slug: intro-windows-ops-readiness
author: >
Jay Vyas (Tesla),
Amim Knabben (Broadcom),
Tatenda Zifudzi (AWS)
---
**Authors:** Jay Vyas (Tesla), Amim Knabben (Broadcom), and Tatenda Zifudzi (AWS)
Since Windows support [graduated to stable](/blog/2019/03/25/kubernetes-1-14-release-announcement/)
with Kubernetes 1.14 in 2019, the capability to run Windows workloads has been much
appreciated by the end user community. The level of and availability of Windows workload

4
content/en/blog/_posts/2024-04-05-diy-create-your-own-cloud-with-kubernetes-part-1/index.md
View File

@ -3,10 +3,10 @@ layout: blog
title: "DIY: Create Your Own Cloud with Kubernetes (Part 1)"
slug: diy-create-your-own-cloud-with-kubernetes-part-1
date: 2024-04-05T07:30:00+00:00
author: >
Andrei Kvapil (Ænix)
---
**Author**: Andrei Kvapil (Ænix)
At Ænix, we have a deep affection for Kubernetes and dream that all modern technologies will soon
start utilizing its remarkable patterns.

4
content/en/blog/_posts/2024-04-05-diy-create-your-own-cloud-with-kubernetes-part-2/index.md
View File

@ -3,10 +3,10 @@ layout: blog
title: "DIY: Create Your Own Cloud with Kubernetes (Part 2)"
slug: diy-create-your-own-cloud-with-kubernetes-part-2
date: 2024-04-05T07:35:00+00:00
author: >
Andrei Kvapil (Ænix)
---
**Author**: Andrei Kvapil (Ænix)
Continuing our series of posts on how to build your own cloud using just the Kubernetes ecosystem.
In the [previous article](/blog/2024/04/05/diy-create-your-own-cloud-with-kubernetes-part-1/), we
explained how we prepare a basic Kubernetes distribution based on Talos Linux and Flux CD.

4
content/en/blog/_posts/2024-04-05-diy-create-your-own-cloud-with-kubernetes-part-3/index.md
View File

@ -3,10 +3,10 @@ layout: blog
title: "DIY: Create Your Own Cloud with Kubernetes (Part 3)"
slug: diy-create-your-own-cloud-with-kubernetes-part-3
date: 2024-04-05T07:40:00+00:00
author: >
Andrei Kvapil (Ænix)
---
**Author**: Andrei Kvapil (Ænix)
Approaching the most interesting phase, this article delves into running Kubernetes within
Kubernetes. Technologies such as Kamaji and Cluster API are highlighted, along with their
integration with KubeVirt.

6
content/en/blog/_posts/2024-04-11-SIG-Architecture-Code-Organization-Spotlight.md
View File

@ -4,14 +4,14 @@ title: "Spotlight on SIG Architecture: Code Organization"
slug: sig-architecture-code-spotlight-2024
canonicalUrl: https://www.kubernetes.dev/blog/2024/04/11/sig-architecture-code-spotlight-2024
date: 2024-04-11
author: >
Frederico Muñoz (SAS Institute)
---
**Author: Frederico Muñoz (SAS Institute)**
_This is the third interview of a SIG Architecture Spotlight series that will cover the different
subprojects. We will cover [SIG Architecture: Code Organization](https://github.com/kubernetes/community/blob/e44c2c9d0d3023e7111d8b01ac93d54c8624ee91/sig-architecture/README.md#code-organization)._
In this SIG Architecture spotlight I talked with [Madhav Jivrajan](https://github.com/MadhavJivrajani)
In this SIG Architecture spotlight I talked with [Madhav Jivrajani](https://github.com/MadhavJivrajani)
(VMware), a member of the Code Organization subproject.
## Introducing the Code Organization subproject

4
content/en/case-studies/_index.html
View File

@ -5,6 +5,10 @@ bigheader: Kubernetes User Case Studies
abstract: A collection of users running Kubernetes in production.
layout: basic
class: gridPage
body_class: caseStudies
cid: caseStudies
menu:
main:
weight: 60
---

15
content/en/docs/concepts/cluster-administration/system-traces.md
View File

@ -22,6 +22,9 @@ with the gRPC exporter and can be collected and routed to tracing backends using
## Trace Collection
Kubernetes components have built-in gRPC exporters for OTLP to export traces, either with an OpenTelemetry Collector,
or without an OpenTelemetry Collector.
For a complete guide to collecting traces and using the collector, see
[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/).
However, there are a few things to note that are specific to Kubernetes components.
@ -47,6 +50,16 @@ service:
exporters: [logging]
```
To directly emit traces to a backend without utilizing a collector,
specify the endpoint field in the Kubernetes tracing configuration file with the desired trace backend address.
This method negates the need for a collector and simplifies the overall structure.
For trace backend header configuration, including authentication details, environment variables can be used with `OTEL_EXPORTER_OTLP_HEADERS`,
see [OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/).
Additionally, for trace resource attribute configuration such as Kubernetes cluster name, namespace, Pod name, etc.,
environment variables can also be used with `OTEL_RESOURCE_ATTRIBUTES`, see [OTLP Kubernetes Resource](https://opentelemetry.io/docs/specs/semconv/resource/k8s/).
## Component traces
### kube-apiserver traces
@ -129,4 +142,6 @@ there are no guarantees of backwards compatibility for tracing instrumentation.
## {{% heading "whatsnext" %}}
* Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
* Read about [OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)

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

@ -616,7 +616,7 @@ available amount is simultaneously allocated to Pods.
The API server restricts quantities of extended resources to whole numbers.
Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
_invalid_ quantities are `0.5` and `1500m`.
_invalid_ quantities are `0.5` and `1500m` (because `1500m` would result in `1.5`).
{{< note >}}
Extended resources replace Opaque Integer Resources.

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

@ -641,7 +641,7 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep
You can expose a Service in multiple ways that don't directly involve the Ingress resource:
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport)
## {{% heading "whatsnext" %}}

15
content/en/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -161,12 +161,17 @@ When `.spec.suspend` changes from `true` to `false` on an existing CronJob witho
### Jobs history limits
The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional.
These fields specify how many completed and failed Jobs should be kept.
By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping
none of the corresponding kind of Jobs after they finish.
The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields specify
how many completed and failed Jobs should be kept. Both fields are optional.
For another way to clean up Jobs automatically, see [Clean up finished Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
* `.spec.successfulJobsHistoryLimit`: This field specifies the number of successful finished
jobs to keep. The default value is `3`. Setting this field to `0` will not keep any successful jobs.
* `.spec.failedJobsHistoryLimit`: This field specifies the number of failed finished jobs to keep.
The default value is `1`. Setting this field to `0` will not keep any failed jobs.
For another way to clean up Jobs automatically, see
[Clean up finished Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
### Time zones

2
content/en/docs/concepts/workloads/controllers/job.md
View File

@ -809,7 +809,7 @@ reset to the current time. This means that the `.spec.activeDeadlineSeconds`
timer will be stopped and reset when a Job is suspended and resumed.
When you suspend a Job, any running Pods that don't have a status of `Completed`
will be [terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
will be [terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
with a SIGTERM signal. The Pod's graceful termination period will be honored and
your Pod must handle this signal in this period. This may involve saving
progress for later or undoing changes. Pods terminated this way will not count

4
content/en/docs/concepts/workloads/pods/_index.md
View File

@ -167,6 +167,10 @@ Each controller for a workload resource uses the `PodTemplate` inside the worklo
object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
workload resource you used to run your app.
When you create a Pod, you can include
[environment variables](/docs/tasks/inject-data-application/define-environment-variable-container/)
in the Pod template for the containers that run in the Pod.
The sample below is a manifest for a simple Job with a `template` that starts one
container. The container in that Pod prints a message then pauses.

2
content/en/docs/home/_index.md
View File

@ -64,4 +64,6 @@ cards:
- name: about
title: About the documentation
description: This website contains documentation for the current and previous 4 versions of Kubernetes.
button: "See available versions"
button_path: "/docs/home/supported-doc-versions"
---

7
content/en/docs/home/supported-doc-versions.md
View File

@ -2,10 +2,7 @@
title: Available Documentation Versions
content_type: custom
layout: supported-versions
card:
name: about
weight: 10
title: Available Documentation Versions
weight: 10
---
This website contains documentation for the current version of Kubernetes
@ -14,4 +11,4 @@ and the four previous versions of Kubernetes.
The availability of documentation for a Kubernetes version is separate from whether
that release is currently supported.
Read [Support period](/releases/patch-releases/#support-period) to learn about
which versions of Kubernetes are officially supported, and for how long.
which versions of Kubernetes are officially supported, and for how long.

2
content/en/docs/reference/kubectl/quick-reference.md
View File

@ -78,7 +78,7 @@ kubectl config view --raw
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
# get the certificate for the e2e user
kubectl config view --raw -o jsonpath='{.users[?(.name == 'e2e')].user.client-certificate-data}' | base64 -d
kubectl config view --raw -o jsonpath='{.users[?(.name == "e2e")].user.client-certificate-data}' | base64 -d
kubectl config view -o jsonpath='{.users[].name}' # display the first user
kubectl config view -o jsonpath='{.users[*].name}' # get a list of users

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

@ -2059,6 +2059,25 @@ on an existing Service object. See the AWS documentation on this topic for more
details.
{{< /caution >}}
### service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset (deprecated) {#service-beta-kubernetes-azure-load-balancer-disble-tcp-reset}
Example: `service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset: "false"`
Used on: Service
This annotation only works for Azure standard load balancer backed service.
This annotation is used on the Service to specify whether the load balancer
should disable or enable TCP reset on idle timeout. If enabled, it helps
applications to behave more predictably, to detect the termination of a connection,
remove expired connections and initiate new connections.
You can set the value to be either true or false.
See [Load Balancer TCP Reset](https://learn.microsoft.com/en-gb/azure/load-balancer/load-balancer-tcp-reset) for more information.
{{< note >}}
This annotation is deprecated.
{{< /note >}}
### pod-security.kubernetes.io/enforce
Type: Label

6
content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
View File

@ -191,8 +191,10 @@ and CSR approval for a new node:
2. Modify the resulted `kubelet.conf` manually to adjust the cluster name and the server endpoint,
or run `kubeadm kubeconfig user --config` (it accepts `InitConfiguration`).
If your cluster does not have the `ca.key` file, you must sign the embedded certificates in
the `kubelet.conf` externally.
If your cluster does not have the `ca.key` file, you must sign the embedded certificates in
the `kubelet.conf` externally. For additional information, see
[PKI certificates and requirements](/docs/setup/best-practices/certificates/) and
[Certificate Management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode).
1. Copy the resulting `kubelet.conf` to `/etc/kubernetes/kubelet.conf` on the new node.
2. Execute `kubeadm join` with the flag

2
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -140,7 +140,7 @@ liveness-exec 1/1 Running 1 1m
## Define a liveness HTTP request
Another kind of liveness probe uses an HTTP GET request. Here is the configuration
file for a Pod that runs a container based on the `registry.k8s.io/liveness` image.
file for a Pod that runs a container based on the `registry.k8s.io/e2e-test-images/agnhost` image.
{{% code_sample file="pods/probe/http-liveness.yaml" %}}

2
content/en/docs/tasks/tools/included/verify-kubectl.md
View File

@ -33,7 +33,7 @@ The connection to the server <server-name:port> was refused - did you specify th
For example, if you are intending to run a Kubernetes cluster on your laptop (locally),
you will need a tool like [Minikube](https://minikube.sigs.k8s.io/docs/start/) to be installed first and then re-run the commands stated above.
If kubectl cluster-info returns the url response but you can't access your cluster,
If `kubectl cluster-info` returns the url response but you can't access your cluster,
to check whether it is configured properly, use:
```shell

4
content/en/examples/pods/probe/http-liveness.yaml
View File

@ -7,9 +7,9 @@ metadata:
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- /server
- liveness
livenessProbe:
httpGet:
path: /healthz

6
content/en/releases/patch-releases.md
View File

@ -78,9 +78,9 @@ releases may also occur in between these.
| Monthly Patch Release | Cherry Pick Deadline | Target date |
| --------------------- | -------------------- | ----------- |
| March 2024 | 2024-03-08 | 2024-03-13 |
| April 2024 | 2024-04-12 | 2024-04-17 |
| May 2024 | 2024-05-10 | 2024-05-15 |
| April 2024 | 2024-04-12 | 2024-04-16 |
| May 2024 | 2024-05-10 | 2024-05-14 |
| June 2024 | 2024-06-07 | 2024-06-11 |
## Detailed Release History for Active Branches

4
content/en/training/_index.html
View File

@ -5,6 +5,10 @@ abstract: Training programs, certifications, and partners.
layout: basic
cid: training
class: training
body_class: training
menu:
main:
weight: 30
---
<section class="call-to-action">

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

@ -328,8 +328,8 @@ metadata:
spec:
containers:
- args:
- /server
image: registry.k8s.io/liveness
- liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
livenessProbe:
httpGet:
# lorsque "host" n'est pas défini, "PodIP" sera utilisé

2
content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -102,7 +102,7 @@ liveness-exec 1/1 Running 1 1m
## Définir une requête HTTP de liveness
Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/liveness`.
d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/e2e-test-images/agnhost`.
{{% codenew file="pods/probe/http-liveness.yaml" %}}

4
content/fr/examples/pods/probe/http-liveness.yaml
View File

@ -7,9 +7,9 @@ metadata:
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- /server
- liveness
livenessProbe:
httpGet:
path: /healthz

203
content/ja/blog/_posts/2024-01-23-image-filesystem.md Normal file
View File

@ -0,0 +1,203 @@
---
layout: blog
title: 'Kubernetesでコンテナを別ファイルシステムに格納する設定方法'
date: 2024-01-23
slug: kubernetes-separate-image-filesystem
---
**著者:** Kevin Hannon (Red Hat)
**翻訳者:** Taisuke Okamoto (IDC Frontier Inc), Junya Okabe (University of Tsukuba), nasa9084 (LY Corporation)
Kubernetesクラスターの稼働、運用する上でよくある問題は、ディスク容量が不足することです。
ノードがプロビジョニングされる際には、コンテナイメージと実行中のコンテナのために十分なストレージスペースを確保することが重要です。
通常、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)は`/var`に書き込みます。
これは別のパーティションとして、ルートファイルシステム上に配置できます。
CRI-Oはデフォルトで、コンテナとイメージを`/var/lib/containers`に書き込みますが、containerdはコンテナとイメージを`/var/lib/containerd`に書き込みます。
このブログ記事では、コンテナランタイムがデフォルトのパーティションとは別にコンテンツを保存する方法に注目したいと思います。
これにより、Kubernetesの設定をより柔軟に行うことができ、デフォルトのファイルシステムはそのままに、コンテナストレージ用に大きなディスクを追加する方法が提供されます。
もう少し説明が必要な領域は、Kubernetesがディスクに書き込む場所/内容です。
## Kubernetesディスク使用状況を理解する
Kubernetesには永続(persistent)データと一時(ephemeral)データがあります。
kubeletとローカルのKubernetes固有ストレージのベースパスは設定可能ですが、通常は`/var/lib/kubelet`と想定されています。
Kubernetesのドキュメントでは、これは時々ルートファイルシステムまたはノードファイルシステムと呼ばれます。
このデータの大部分は、次のようにカテゴリー分けされます。
- エフェメラルストレージ
- ログ
- コンテナランタイム
ルート/ノード・ファイルシステムは`/`ではなく、`/var/lib/kubelet`があるディスクのため、ほとんどのPOSIXシステムとは異なります。
### エフェメラルストレージ
Podやコンテナは、動作に一時的または短期的なローカルストレージを必要とする場合があります。
エフェメラルストレージの寿命は個々のPodの寿命を超えず、エフェメラルストレージはPod間で共有することはできません。
### ログ
デフォルトでは、Kubernetesは各実行中のコンテナのログを`/var/log`内のファイルとして保存します。
これらのログは一時的であり、ポッドが実行されている間に大きくなりすぎないようにkubeletによって監視されます。
各ノードの[ログローテーション](/ja/docs/concepts/cluster-administration/logging/#log-rotation)設定をカスタマイズしてこれらのログのサイズを管理し、ノードローカルストレージに依存しないためにログの配信を設定することができます(サードパーティーのソリューションを使用)。
### コンテナランタイム
コンテナランタイムには、コンテナとイメージのための2つの異なるストレージ領域があります。
- 読み取り専用レイヤー:イメージは通常、コンテナが実行されている間に変更されないため、読み取り専用レイヤーとして表されます。読み取り専用レイヤーには、複数のレイヤーが組み合わされて単一の読み取り専用レイヤーになることがあります。コンテナがファイルシステムに書き込んでいる場合、コンテナの上にはエフェメラルストレージを提供する薄いレイヤーがあります。
- 書き込み可能レイヤー:コンテナランタイムによっては、ローカルの書き込みがレイヤー化された書き込みメカニズム(たとえば、Linux上の`overlayfs`やWindows上のCimFS)として実装されることがあります。これは書き込み可能レイヤーと呼ばれます。ローカルの書き込みは、コンテナイメージの完全なクローンで初期化された書き込み可能なファイルシステムを使用する場合もあります。これは、ハイパーバイザ仮想化に基づく一部のランタイムで使用されます。
コンテナランタイムのファイルシステムには、読み取り専用レイヤーと書き込み可能レイヤーの両方が含まれます。これはKubernetesドキュメントでは`imagefs`と見なされています。
## コンテナランタイムの構成
### CRI-O
CRI-Oは、コンテナランタイムが永続データと一時データをどのように保存するかを制御するためのTOML形式のストレージ構成ファイルを使用します。
CRI-Oは[ストレージライブラリ](https://github.com/containers/storage)を利用します。
一部のLinuxディストリビューションには、ストレージに関するマニュアルエントリ(`man 5 containers-storage.conf`)があります。
ストレージの主な設定は、`/etc/containers/storage.conf`にあり、一時データの場所やルートディレクトリを制御することができます。
ルートディレクトリは、CRI-Oが永続データを保存する場所です。
```toml
[storage]
# Default storage driver
driver = "overlay"
# Temporary storage location
runroot = "/var/run/containers/storage"
# Primary read/write location of container storage
graphroot = "/var/lib/containers/storage"
```
- `graphroot`
- コンテナランタイムから保存される永続データを指します
- SELinuxが有効になっている場合、これは`/var/lib/containers/storage`と一致させる必要があります
- `runroot`
- コンテナに対する一時的な読み書きアクセスを提供します
- これは一時ファイルシステムに配置することを推奨します
ここでは、`/var/lib/containers/storage`に合うようにgraphrootディレクトリのラベルを変更する簡単な方法を紹介します:
```bash
semanage fcontext -a -e /var/lib/containers/storage <YOUR-STORAGE-PATH>
restorecon -R -v <YOUR-STORAGE-PATH>
```
### containerd
コンテナランタイムであるcontainerdは、永続データと一時データの保存先を制御するためのTOML形式の構成ファイルを使用します。構成ファイルのデフォルトパスは、`/etc/containerd/config.toml`にあります。
containerdストレージの関連フィールドは、`root`と`state`です。
- `root`
- containerdのメタデータのルートディレクトリ
- デフォルトは`/var/lib/containerd`です
- また、OSがそれを要求する場合は、ルートにSELinuxラベルも必要です
- `state`
- containerdの一時データ
- デフォルトは、`/run/containerd`です
## Kubernetesノードの圧迫による退避
Kubernetesは、コンテナファイルシステムがノードファイルシステムと分離されているかどうかを自動的に検出します。
ファイルシステムを分離する場合、Kubernetesはノードファイルシステムとコンテナランタイムファイルシステムの両方を監視する責任があります。
Kubernetesドキュメントでは、ノードファイルシステムとコンテナランタイムファイルシステムをそれぞれnodefsとimagefsと呼んでいます。
nodefsまたはimagefsのいずれかがディスク容量不足になると、ノード全体がディスク圧迫があると見なされます。
Kubernetesは、まず未使用のコンテナやイメージを削除してスペースを回収し、その後にポッドを追い出すことでスペースを再利用します。
nodefsとimagefsの両方を持つノードでは、kubeletはimagefs上の未使用のコンテナイメージを[ガベージコレクト](/ja/docs/concepts/architecture/garbage-collection/#containers-images)し、nodefsからは終了したポッドとそれらのコンテナを削除します。
nodefsのみが存在する場合、Kubernetesのガベージコレクションには、終了したコンテナ、ポッド、そして未使用のイメージが含まれます。
Kubernetesでは、ディスクがいっぱいかどうかを判断するためのより多くの構成が可能です。
kubelet内の退避マネージャーには、関連する閾値を制御するいくつかの構成設定があります。
ファイルシステムの場合、関連する測定値は`nodefs.available`、`nodefs.inodesfree`、`imagefs.available`、および`imagefs.inodesfree`です。
コンテナランタイム用に専用のディスクがない場合、imagefsは無視されます。
ユーザーは、既存のデフォルト値を使用できます:
- `memory.available` < 100MiB
- `nodefs.available` < 10%
- `imagefs.available` < 15%
- `nodefs.inodesFree` < 5% (Linuxノード)
Kubernetesでは、kubeletの構成ファイル内の`EvictionHard`と`EvictionSoft`にユーザー定義の値を設定することができます。
`EvictionHard`
限界値を定義します。これらの限界値を超えると、Grace Periodなしでポッドが追い出されます。
`EvictionSoft`
限界値を定義します。これらの限界値を超えると、Grace Periodが設定されたシグナルごとにポッドが追い出されます。
`EvictionHard`の値を指定すると、デフォルト値が置き換えられます。
したがって、すべてのシグナルを設定することが重要です。
たとえば、次に示すkubeletの設定は、[退避シグナル](/docs/concepts/scheduling-eviction/node-pressure-eviction/#eviction-signals-and-thresholds)と猶予期間オプションを設定するために使用できます。
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
memory.available: "100Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
imagefs.inodesFree: "5%"
evictionSoft:
memory.available: "100Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
imagefs.inodesFree: "5%"
evictionSoftGracePeriod:
memory.available: "1m30s"
nodefs.available: "2m"
nodefs.inodesFree: "2m"
imagefs.available: "2m"
imagefs.inodesFree: "2m"
evictionMaxPodGracePeriod: 60s
```
## 問題点
Kubernetesプロジェクトでは、退避のデフォルト設定を使用するか、退避に関連するすべてのフィールドを設定することをお勧めしています。
デフォルト設定を使用するか、独自の`evictionHard`設定を指定できます。
シグナルの設定を忘れると、Kubernetesはそのリソースを監視しません。
管理者やユーザーが遭遇する可能性のある一般的な設定ミスの1つは、新しいファイルシステムを`/var/lib/containers/storage`または`/var/lib/containerd`にマウントすることです。
Kubernetesは別のファイルシステムを検出するため、これを行った場合は`imagefs.inodesfree`と`imagefs.available`が必要に応じて設定に一致していることを確認する必要があります。
もう一つの混乱の領域は、イメージファイルシステムをノードに定義した場合でも、エフェメラルストレージの報告が変わらないことです。
イメージファイルシステム(`imagefs`)は、コンテナイメージのレイヤーを保存するために使用されます。
コンテナが自分自身のルートファイルシステムに書き込む場合、そのローカルな書き込みはコンテナイメージのサイズには含まれません。
コンテナランタイムがこれらのローカルな変更を保存する場所は、ランタイムによって定義されますが、通常はイメージファイルシステムです。
Pod内のコンテナがファイルシステムをバックエンドとする`emptyDir`ボリュームに書き込んでいる場合、これはノードファイルシステムからスペースを使用します。
kubeletは常に、`nodefs`で表されるファイルシステムに基づいてエフェメラルストレージの容量と割り当てを報告します。
これは、実際には一時的な書き込みがイメージファイルシステムに行われている場合に混乱の原因となる可能性があります。
## 今後の課題
[KEP-4191](https://github.com/kubernetes/enhancements/issues/4191)に取り組むことで、エフェメラルの報告の制限を解消し、コンテナランタイムにより多くの構成オプションを提供することが期待されています。
この提案では、Kubernetesは書き込み可能なレイヤーが読み取り専用のレイヤー(イメージ)と分離されているかどうかを検出します。
これにより、書き込み可能なレイヤーを含むすべてのエフェメラルストレージを同じディスクに配置することが可能になります。
また、イメージ用に別のディスクを使用することも可能になります。
## 参加するためにはどうすればよいですか？
参加したい場合は、Kubernetesの[SIG Node](https://github.com/kubernetes/community/tree/master/sig-node)に参加することができます。
フィードバックを共有したい場合は、Slackチャンネルの[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G)で行うことができます。
まだそのSlackワークスペースに参加していない場合は、[https://slack.k8s.io/](https://slack.k8s.io/)から招待状を取得できます。
素晴らしいレビューを提供し、貴重な洞察を共有し、トピックのアイデアを提案してくれたすべてのコントリビューターに特別な感謝を捧げます。
- Peter Hunt
- Mrunal Patel
- Ryan Phillips
- Gaurav Singh

2
content/ja/community/code-of-conduct.md
View File

@ -9,7 +9,7 @@ css: /css/community.css
<h1>Kubernetesコミュニティ行動規範</h1>
Kubernetesは、<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/jp.md">CNCF行動規範</a>に従います。
以下のCNCFの行動規範のテキストは、<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct-languages/jp.md">commit 214585e</a>から複製したものです。この掲示が古くなっていることに気がついた場合には、<a href="https://github.com/kubernetes/website/issues/new">issueを作成</a>してください。
以下のCNCFの行動規範のテキストは、<a href="https://github.com/cncf/foundation/blob/c9a48490c92ae435c66d53f9a826cd7df4336766/code-of-conduct-languages/ja.md">commit c9a4849</a>から複製したものです。この掲示が古くなっていることに気がついた場合には、<a href="https://github.com/kubernetes/website/issues/new">issueを作成</a>してください。
イベント、ミーティング、Slack、その他のコミュニケーション手段において行動規範の違反を見つけた場合には、<a href="https://git.k8s.io/community/committee-code-of-conduct">Kubernetes Code of Conduct Committee(行動規範委員会)</a>に連絡してください。連絡はメールアドレス<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>から行えます。連絡者の匿名性は守られます。

88
content/ja/community/static/cncf-code-of-conduct.md
View File

@ -1,32 +1,84 @@
<!-- Do not edit this file directly. Get the latest from
https://github.com/cncf/foundation/blob/master/code-of-conduct/jp.md -->
https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/jp.md -->
CNCF コミュニティ行動規範 v1.0
CNCF コミュニティ行動規範 v1.3
------------------------------
### コントリビューター行動規範
## コミュニティの行動規範
本プロジェクトのコントリビューターおよびメンテナーとして、オープンかつ快適なコミュニティを促進するために、私たちは、問題の報告、機能要求の投稿、ドキュメントの更新、プル要求またはパッチの送信、および他の活動を通して貢献するすべての人々を尊重することを誓います。
CNCFコミュニティのコントリビューター、メンテナ、および参加者は、オープンかつ快適なコミュニティを促進するために、問題の報告、機能要求の投稿、ドキュメントの更新、プルリクエストまたはパッチの送信、カンファレンスやイベントへの参加、または他のコミュニティ、プロジェクト活動を通して参加または貢献するすべての人々を尊重することを誓います。
私たちは、経験レベル、性別、性の自認および表明、性的嗜好、障がい、個人的な外見、身体の大きさ、人種、民族、年齢、宗教、または国籍に関係なく、このプロジェクトへの参加を、全員にとってハラスメントがない経験にすることを約束します。
私たちは、年齢、身体の大きさ、カースト、障害、民族性、経験レベル、家族構成、性別、性自認と性表現、配偶者の有無、軍人または退役軍人の地位、国籍、容姿、人種、宗教、性的指向、社会経済的地位、部族、またはその他あらゆる多様性の側面に関係なく、CNCFコミュニティへの参加を、全員にとってハラスメントがない経験にすることを約束します。
認められない参加者の行動の例:
## 適用範囲
- 性的な言語またはイメージの使用
- 個人的な攻撃
- 煽りや侮辱/軽蔑的なコメント
- 公開または非公開のハラスメント
- 明示的な許可なく、物理的な住所や電子アドレスなど、他者の個人情報を公開すること
- 他の倫理または職業倫理に反する行為。
本行動規範の適用範囲：
プロジェクト メンテナーは、本行動規範に準拠していないコメント、コミット、コード、Wiki 編集、問題、他のコントリビューションを削除、編集、または却下する権利および責任を有しています。プロジェクト メンテナーは、本行動規範を採用することで、公正かつ一貫した方法で、これらの原則を本プロジェクトの管理におけるすべての要素に適用することに注力します。本行動規範を遵守または施行しないプロジェクト メンテナーは、永久的にプロジェクト チームから抹消される可能性があります。
個人がプロジェクトまたはコミュニティを代表するときには、本行動規範は、プロジェクト スペースおよび公共のスペースの両方に適用されます。
Kubernetesで虐待的、嫌がらせ、または許されない行動があった場合には、<conduct@kubernetes.io>から[Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct)（行動規範委員会）にご連絡ください。その他のプロジェクトにつきましては、CNCFプロジェクト管理者または仲介者<mishi@linux.com>にご連絡ください。
* プロジェクトやコミュニティのスペース内
* CNCFコミュニティ参加者の言葉や行動が、CNCFプロジェクト、CNCFコミュニティ、または他のCNCFコミュニティ参加者に向けられる、またはそれらに関連する場合の他のスペース内
本行動規範は、コントリビューターの合意 (https://contributor-covenant.org) バージョン 1.2.0 https://contributor-covenant.org/version/1/2/0/ から適応されています。
## CNCFイベント
### CNCF イベント行動規範
Linux Foundationのプロフェッショナルなイベントスタッフによって制作されるCNCFイベントに関しては、イベントページにあるLinux Foundationの[イベント行動規範](https://events.linuxfoundation.org/code-of-conduct/)に準拠します。これは、CNCF行動規範と併用されることを目的としています。
CNCF イベントは、イベント ページにある Linux Foundation 行動規範 に準拠します。これは、前述のポリシーに対応し、インシデントへの対応に関する詳細を含めることを目的としています。
## 規範
CNCFコミュニティはオープンであり、包括的であり、敬意をもって接されます。コミュニティのすべてのメンバーは、自分自身のアイデンティティが尊重される権利を持っています。
良い環境を構築するための参加者の行動の例は以下のようなものが含まれますが、これらに限定されるものではありません。
* 他人への共感と思いやりを表す
* 異なる意見、視点、経験を尊重する
* 建設的なフィードバックを心がけ、それを快く受け入れる
* ミスに対して責任感を持ち、その影響を受けた人々に謝罪し、その経験から学ぶこと
* 個人だけではなく、コミュニティ全体として何が最善策かを重視する
* 快適で包括的な言葉の使用
一方で、以下のような行動は受け入れられませんが、これらに限定されるものではありません。
* 性的な言語や描写の使用
* 煽りや侮辱的、軽蔑的なコメント、および個人または政治的な攻撃
* あらゆる形態の公開または非公開のハラスメント
* 明示的な許可なしに他人の個人情報(住所やメールアドレス)を公開すること
* 暴力、脅迫、またはこれらの行為を助長する行為
* ストーカー行為やその人の意思に反した追跡行為をすること
* 望ましくない身体的な接触
* 歓迎されない性的または恋愛的な注目や誘い
* その他、プロフェッショナルな場において不適切とみなされうる行為
また、次のような行動も禁止されています。
* 行動規範の調査に関連して故意に誤った情報や誤解を招く情報を提供する、あるいは調査を故意に妨害する。
* インシデントを報告したり、証人としてインシデントに関する情報を提供したりした人へ対する報復行為。
プロジェクトのメンテナは、この行動規範に準拠していないコメント、コミット、コード、Wikiの編集、問題、他のコントリビューションを削除、編集、または却下する権利および責任を持っています。プロジェクトのメンテナは、本行動規範を採用することで、公正かつ一貫した方法で、これらの原則をCNCFプロジェクトの管理におけるすべての要素に適用することに注力します。本行動規範を遵守または施行しないプロジェクトのメンテナは、一時的あるいは永久的にプロジェクトのチームから抹消される可能性があります。
## 報告
Kubernetesコミュニティにて問題が発生した場合には、[conduct@kubernetes.io](mailto:conduct@kubernetes.io)から[Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct)(行動規範委員会)までご連絡ください。通常3営業日以内に返信致します。
その他のプロジェクトや複数のプロジェクトに影響を与えるインシデントにつきましては、[CNCFの行動規範委員会](https://www.cncf.io/conduct/committee/)(email: [conduct@cncf.io](mailto:conduct@cncf.io))までご連絡ください。あるいは、[CNCFの行動規範委員会](https://www.cncf.io/conduct/committee/)の個別のメンバーに報告することもできます。報告の手順や匿名での報告方法など、より詳細な情報は、[インシデント解決手順](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md)をご覧ください。通常3営業日以内に返信致します。
Linux Foundationが制作するCNCFイベントでのインシデントについては、[eventconduct@cncf.io](mailto:eventconduct@cncf.io)にご連絡ください。
## 施行
報告されたインシデントのレビューと調査の後、管轄するCoCの対応チームは、この行動規範と関連するドキュメントに基づいて、適切な行動を決定します。
プロジェクトリーダーシップが取り扱う行動規範のインシデント、CNCF行動規範委員会が取り扱うインシデント、およびLinux Foundation(そのイベントチームを含む)が取り扱うインシデントに関する情報には、私たちの[管轄ポリシー](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md)を参照してください。
## 改正
CNCFの憲章と一貫して、この行動規範に対する実質的な変更は、Technical Oversight Committeeの承認が必要です。
## 謝辞
本行動規範は、コントリビューター行動規範([http://contributor-covenant.org](http://contributor-covenant.org/))に基づいています。バージョン 2.0はこちらから参照可能です。[http://contributor-covenant.org/version/2/0/code_of_conduct/](http://contributor-covenant.org/version/2/0/code_of_conduct/)

4
content/ja/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -31,7 +31,7 @@ APIサーバーに接続したい{{< glossary_tooltip text="Pod" term_id="pod" >
コントロールプレーン(APIサーバー)からノードへの主要な通信経路は2つあります。
1つ目は、APIサーバーからクラスター内の各ノードで実行される{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}プロセスへの通信経路です。
2つ目は、APIサーバーの _プロキシー_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
2つ目は、APIサーバーの _プロキシ_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
### APIサーバーからkubeletへの通信 {#api-server-to-kubelet}
@ -67,7 +67,7 @@ SSHトンネルは現在非推奨であるため、自分が何をしている
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシーを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
Konnectivityエージェントは、Konnectivityサーバーへの接続を開始し、ネットワーク接続を維持します。
Konnectivityサービスを有効にすると、コントロールプレーンからノードへのトラフィックは、すべてこの接続を経由するようになります。

28
content/ja/docs/concepts/cluster-administration/proxies.md
View File

@ -1,47 +1,47 @@
---
title: Kubernetesのプロキシー
title: Kubernetesのプロキシ
content_type: concept
weight: 100
---
<!-- overview -->
このページではKubernetesと併用されるプロキシーについて説明します。
このページではKubernetesと併用されるプロキシについて説明します。
<!-- body -->
## プロキシー
## プロキシ
Kubernetesを使用する際に、いくつかのプロキシーを使用する場面があります。
Kubernetesを使用する際に、いくつかのプロキシを使用する場面があります。
1. [kubectlのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
1. [kubectlのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- ユーザーのデスクトップ上かPod内で稼働します
- ローカルホストのアドレスからKubernetes apiserverへのプロキシーを行います
- クライアントからプロキシー間ではHTTPを使用します
- プロキシーからapiserverへはHTTPSを使用します
- ローカルホストのアドレスからKubernetes apiserverへのプロキシを行います
- クライアントからプロキシ間ではHTTPを使用します
- プロキシからapiserverへはHTTPSを使用します
- apiserverの場所を示します
- 認証用のヘッダーを追加します
1. [apiserverのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
1. [apiserverのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- apiserver内で動作する踏み台となります
- これがなければ到達不可能であるクラスターIPへ、クラスターの外部からのユーザーを接続します
- apiserverのプロセス内で稼働します
- クライアントからプロキシー間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
- プロキシーからターゲット間では利用可能な情報を使用して、プロキシーによって選択されたHTTPかHTTPSのいずれかを使用します
- クライアントからプロキシ間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
- プロキシからターゲット間では利用可能な情報を使用して、プロキシによって選択されたHTTPかHTTPSのいずれかを使用します
- Node、Pod、Serviceへ到達するのに使えます
- Serviceへ到達するときは負荷分散を行います
1. [kube proxy](/ja/docs/concepts/services-networking/service/#ips-and-vips):
- 各ノード上で稼働します
- UDP、TCP、SCTPをプロキシーします
- UDP、TCP、SCTPをプロキシします
- HTTPを解釈しません
- 負荷分散機能を提供します
- Serviceへ到達させるためのみに使用されます
1. apiserverの前段にあるプロキシー/ロードバランサー:
1. apiserverの前段にあるプロキシ/ロードバランサー:
- 実際に存在するかどうかと実装はクラスターごとに異なります(例: nginx)
- 全てのクライアントと、1つ以上のapiserverの間に位置します
@ -59,7 +59,7 @@ Kubernetesユーザーのほとんどは、最初の2つのタイプ以外に心
## リダイレクトの要求
プロキシーはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
プロキシはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。

4
content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
View File

@ -108,9 +108,9 @@ kubectl config view
kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。
## プロキシー
## プロキシ
kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシーを使用するように`kubectl`を設定することができます。
kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシを使用するように`kubectl`を設定することができます。
```yaml
apiVersion: v1

2
content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -16,7 +16,7 @@ weight: 20
## アグリゲーションレイヤー
アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします。
アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシします。
APIServiceを実装する最も一般的な方法は、クラスター内で実行されるPodで*拡張APIサーバー* を実行することです。クラスター内のリソース管理に拡張APIサーバーを使用している場合、拡張APIサーバー("extension-apiserver"とも呼ばれます)は通常、1つ以上の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}とペアになっています。apiserver-builderライブラリは、拡張APIサーバーと関連するコントローラーの両方にスケルトンを提供します。

2
content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの
Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
アグリゲートAPIは、プロキシとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。

2
content/ja/docs/concepts/services-networking/connect-applications-service.md
View File

@ -138,7 +138,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m
クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
この仕組みに興味がある場合は、[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
この仕組みに興味がある場合は、[サービスプロキシ](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
## Serviceにアクセスする

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

@ -40,11 +40,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
* [Kusk Gateway](https://kusk.kubeshop.io/)は[Envoy](https://www.envoyproxy.io)をベースにしたOpenAPIドリブンのIngressコントローラーです。
* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシーとして)動作します。
* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
* [ngrok Kubernetes Ingress Controller](https://github.com/ngrok/kubernetes-ingress-controller)は、[ngrok platform](https://ngrok.com)を使用するK8sサービスに安全な公開アクセスを追加するためのオープンソースコントローラーです。
* [OCI Native Ingress Controller](https://github.com/oracle/oci-native-ingress-controller#readme)は、Oracle Cloud Infrastructure用のIngressコントローラーであり、[OCI Load Balancer](https://docs.oracle.com/ja-jp/iaas/Content/Balance/home.htm)を管理することができます。
* [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html)は[Pomerium](https://pomerium.com/)ベースのものであり、コンテキストを考慮したアクセスポリシーを提供します。
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシです。
* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://traefik.io/traefik/) proxy向けのIngressコントローラーです。
* [Tyk Operator](https://github.com/TykTechnologies/tyk-operator)はAPI管理機能をIngressに持たせるためにCustom ResourcesでAPIを拡張します。Tyk OperatorはOpen Source Tyk GatewayとTyk Cloudコントロールプレーンで動作します。
* [Voyager](https://voyagermesh.com)は、[HAProxy](https://www.haproxy.org/#desc)向けのIngressコントローラーです。

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

@ -53,7 +53,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
Ingressには`apiVersion`、`kind`、`metadata`や`spec`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
`ingressClassName`が省略された場合、[デフォルトのIngressClass](#default-ingress-class)を定義する必要があります。

64
content/ja/docs/concepts/services-networking/service.md
View File

@ -70,7 +70,7 @@ spec:
この定義では、"my-service"という名前のついた新しいServiceオブジェクトを作成します。これは`app=Myapp`ラベルのついた各Pod上でTCPの9376番ポートをターゲットとします。
Kubernetesは、このServiceに対してIPアドレス("clusterIP"とも呼ばれます)を割り当てます。これはServiceのプロキシーによって使用されます(下記の[仮想IPとServiceプロキシー](#virtual-ips-and-service-proxies)を参照ください)。
Kubernetesは、このServiceに対してIPアドレス("clusterIP"とも呼ばれます)を割り当てます。これはServiceのプロキシによって使用されます(下記の[仮想IPとServiceプロキシ](#virtual-ips-and-service-proxies)を参照ください)。
Serviceセレクターのコントローラーはセレクターに一致するPodを継続的にスキャンし、“my-service”という名前のEndpointsオブジェクトに対して変更をPOSTします。
@ -151,35 +151,35 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊
`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。
この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。
## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
## 仮想IPとサービスプロキシ {#virtual-ips-and-service-proxies}
Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
### なぜ、DNSラウンドロビンを使わないのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。
ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシに頼るのでしょうか。
他のアプローチはどうなのでしょうか。例えば、複数のAバリュー(もしくはIPv6用にAAAAバリューなど)をもつDNSレコードを設定し、ラウンドロビン方式で名前を解決することは可能でしょうか。
Serviceにおいてプロキシーを使う理由はいくつかあります。
Serviceにおいてプロキシを使う理由はいくつかあります。
* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
### user-spaceプロキシーモード {#proxy-mode-userspace}
### user-spaceプロキシモード {#proxy-mode-userspace}
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointsを介して通知されたPodに対して)。
各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシされます(Endpointsを介して通知されたPodに対して)。
kube-proxyは、どのバックエンドPodを使うかを決める際にServiceの`SessionAffinity`項目の設定を考慮に入れます。
最後に、user-spaceプロキシーはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。
そのルールは、トラフィックをバックエンドPodにプロキシーするためのプロキシーポートにリダイレクトします。
最後に、user-spaceプロキシはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。
そのルールは、トラフィックをバックエンドPodにプロキシするためのプロキシポートにリダイレクトします。
デフォルトでは、user-spaceモードにおけるkube-proxyはラウンドロビンアルゴリズムによってバックエンドPodを選択します。
![user-spaceプロキシーのService概要ダイアグラム](/images/docs/services-userspace-overview.svg)
![user-spaceプロキシのService概要ダイアグラム](/images/docs/services-userspace-overview.svg)
### `iptables`プロキシーモード {#proxy-mode-iptables}
### `iptables`プロキシモード {#proxy-mode-iptables}
このモードでは、kube-proxyはServiceやEndpointsオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。
各Serviceでは、そのServiceの`clusterIP`と`port`に対するトラフィックをキャプチャするiptablesルールをインストールし、そのトラフィックをServiceのあるバックエンドのセットに対してリダイレクトします。
@ -195,9 +195,9 @@ kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応
iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。
![iptablesプロキシーのService概要ダイアグラム](/images/docs/services-iptables-overview.svg)
![iptablesプロキシのService概要ダイアグラム](/images/docs/services-iptables-overview.svg)
### IPVSプロキシーモード {#proxy-mode-ipvs}
### IPVSプロキシモード {#proxy-mode-ipvs}
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
@ -205,9 +205,9 @@ iptablesモードのkube-proxyが正常なバックエンドPodのみをリダ
このコントロールループはIPVSのステータスが理想的な状態になることを保証します。
Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。
IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。
これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。
他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。
IPVSプロキシモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。
これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシのルールを同期する際にはよりパフォーマンスがよいことを意味します。
他のプロキシモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。
IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
@ -225,9 +225,9 @@ kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュー
もしIPVSカーネルモジュールが見つからなかった場合、kube-proxyはiptablesモードで稼働するようにフォールバックされます。
{{< /note >}}
![IPVSプロキシーのService概要ダイアグラム](/images/docs/services-ipvs-overview.svg)
![IPVSプロキシのService概要ダイアグラム](/images/docs/services-ipvs-overview.svg)
このダイアグラムのプロキシーモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシーされています。
このダイアグラムのプロキシモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシされています。
特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`に"ClientIP"を設定することにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
また、`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`を適切に設定することにより、セッションのタイムアウト時間を設定できます(デフォルトではこの値は18,000で、3時間となります)。
@ -326,7 +326,7 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
例えば、ユーザーはこのAPI上でカスタム{{< glossary_tooltip term_id="operator-pattern" text="オペレーター" >}}を実装することができます。
この`Service`においては、clusterIPは割り当てられず、kube-proxyはこのServiceをハンドリングしないのと、プラットフォームによって行われるはずの
ロードバランシングやプロキシーとしての処理は行われません。DNSがどのように自動で設定されるかは、定義されたServiceが定義されたラベルセレクターを持っているかどうかに依存します。
ロードバランシングやプロキシとしての処理は行われません。DNSがどのように自動で設定されるかは、定義されたServiceが定義されたラベルセレクターを持っているかどうかに依存します。
### ラベルセレクターの利用
@ -352,7 +352,7 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類
* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシも設定されません。
{{< note >}}
`ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
{{< /note >}}
@ -567,9 +567,9 @@ metadata:
2つ目のアノテーションはPodが利用するプロトコルを指定するものです。HTTPSとSSLの場合、ELBはそのPodが証明書を使って暗号化されたコネクションを介して自分自身のPodを認証すると推測します。
HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
HTTPとHTTPSでは、レイヤー7でのプロキシを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
TCPとSSLでは、レイヤー4でのプロキシを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。
いくつかのポートがセキュアに保護され、他のポートではセキュアでないような混合した環境において、下記のようにアノテーションを使うことができます。
@ -581,7 +581,7 @@ TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBは
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"
```
上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。
上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシとなります。
Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。
@ -611,7 +611,7 @@ AWS上で稼働するクラスターで[PROXY protocol](https://www.haproxy.org/
service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
```
Kubernetesバージョン1.3.0からは、このアノテーションを使用するとELBによってプロキシーされた全てのポートが対象になり、そしてそれ以外の場合は構成されません。
Kubernetesバージョン1.3.0からは、このアノテーションを使用するとELBによってプロキシされた全てのポートが対象になり、そしてそれ以外の場合は構成されません。
#### AWS上でのELBのアクセスログ
@ -809,7 +809,7 @@ IPアドレスをハードコードする場合、[Headless Service](#headless-s
{{< /note >}}
`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`my.database.example.com`という値をもつ`CNAME`レコードを返します。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。
後にユーザーが使用しているデータベースをクラスター内に移行することになった場合は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。
{{< warning >}}
@ -851,12 +851,12 @@ spec:
## Serviceの欠点
仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
仮想IP用にuserspaceモードのプロキシを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
これについては、[Serviceのデザインプロポーザル](https://github.com/kubernetes/kubernetes/issues/1107)にてさらなる詳細を確認できます。
userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
userspaceモードのプロキシの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。
iptablesプロキシーモードはクラスター内の送信元IPを不明瞭にはしませんが、依然としてロードバランサーやNodePortへ疎通するクライアントに影響があります。
iptablesプロキシモードはクラスター内の送信元IPを不明瞭にはしませんが、依然としてロードバランサーやNodePortへ疎通するクライアントに影響があります。
`Type`フィールドはネストされた機能としてデザインされています。 - 各レベルの値は前のレベルに対して追加します。
これは全てのクラウドプロバイダーにおいて厳密に要求されていません(例: Google Compute Engineは`LoadBalancer`を動作させるために`NodePort`を割り当てる必要はありませんが、AWSではその必要があります)が、現在のAPIでは要求しています。
@ -886,7 +886,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。
Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
kube-proxyは3つの微妙に異なった動作をするプロキシーモード&mdash; userspace、iptablesとIPVS &mdash; をサポートしています。
kube-proxyは3つの微妙に異なった動作をするプロキシモード&mdash; userspace、iptablesとIPVS &mdash; をサポートしています。
#### Userspace
@ -895,8 +895,8 @@ kube-proxyは3つの微妙に異なった動作をするプロキシーモード
そのServiceのポートが1234で、そのServiceはクラスター内の全てのkube-proxyインスタンスによって監視されていると仮定します。
kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいランダムポートをオープンし、その仮想IPアドレスの新しいポートにリダイレクトするようにiptablesを更新し、そのポート上で新しい接続を待ち受けを開始します。
クライアントがServiceの仮想IPアドレスに接続したとき、iptablesルールが有効になり、そのパケットをプロキシー自身のポートにリダイレクトします。
その"Service プロキシー"はバックエンドPodの対象を選択し、クライアントのトラフィックをバックエンドPodに転送します。
クライアントがServiceの仮想IPアドレスに接続したとき、iptablesルールが有効になり、そのパケットをプロキシ自身のポートにリダイレクトします。
その"Service プロキシ"はバックエンドPodの対象を選択し、クライアントのトラフィックをバックエンドPodに転送します。
これはServiceのオーナーは、衝突のリスクなしに、求めるどのようなポートも選択できることを意味します。
クライアントは単純にそのIPとポートに対して接続すればよく、実際にどのPodにアクセスしているかを意識しません。
@ -910,7 +910,7 @@ Service毎のルールは、トラフィックをバックエンドにリダイ
クライアントがServiceの仮想IPアドレスに対して接続しているとき、そのiptablesルールが有効になります。
バックエンドのPodが選択され(SessionAffinityに基づくか、もしくはランダムで選択される)、パケットはバックエンドにリダイレクトされます。
userspaceモードのプロキシーとは異なり、パケットは決してuserspaceにコピーされず、kube-proxyは仮想IPのために稼働される必要はなく、またNodeでは変更されていないクライアントIPからトラフィックがきます。
userspaceモードのプロキシとは異なり、パケットは決してuserspaceにコピーされず、kube-proxyは仮想IPのために稼働される必要はなく、またNodeでは変更されていないクライアントIPからトラフィックがきます。
このように同じ基本的なフローは、NodePortまたはLoadBalancerを介してトラフィックがきた場合に、実行され、ただクライアントIPは変更されます。
@ -936,7 +936,7 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
### HTTP
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシをセットアップするために、LoadBalancerモードでServiceを作成可能です。
{{< note >}}
ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。

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

@ -286,7 +286,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
{{< note >}}
Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。
{{< /note >}}
1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpointSlice(およびEndpoints)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が*始まる*とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpointSlice(およびEndpoints)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシのような)ロードバランサーが終了猶予期間が*始まる*とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。
1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。
1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。

12
content/ja/docs/reference/access-authn-authz/authentication.md
View File

@ -29,7 +29,7 @@ APIリクエストは、通常のユーザーかサービスアカウントに
## 認証戦略
Kubernetesは、クライアント証明書、Bearerトークン、認証プロキシー、HTTP Basic認証を使い、認証プラグインを通してAPIリクエストを認証します。APIサーバーにHTTPリクエストが送信されると、プラグインは以下の属性をリクエストに関連付けようとします。
Kubernetesは、クライアント証明書、Bearerトークン、認証プロキシ、HTTP Basic認証を使い、認証プラグインを通してAPIリクエストを認証します。APIサーバーにHTTPリクエストが送信されると、プラグインは以下の属性をリクエストに関連付けようとします。
* ユーザー名: エンドユーザーを識別する文字列です。一般的にな値は、`kube-admin`や`jane@example.com`です。
* UID: エンドユーザーを識別する文字列であり、ユーザー名よりも一貫性と一意性を持たせようとするものです。
@ -48,7 +48,7 @@ Kubernetesは、クライアント証明書、Bearerトークン、認証プロ
`system:authenticated`グループには、すべての認証済みユーザーのグループのリストが含まれます。
他の認証プロトコル(LDAP、SAML、Kerberos、X509スキームなど)との統合は、[認証プロキシー](#authenticating-proxy)や[認証Webhook](#webhook-token-authentication)を使用して実施できます。
他の認証プロトコル(LDAP、SAML、Kerberos、X509スキームなど)との統合は、[認証プロキシ](#authenticating-proxy)や[認証Webhook](#webhook-token-authentication)を使用して実施できます。
### X509クライアント証明書
@ -211,7 +211,7 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6
1. Kubernetesには、認証プロセスを起動するための"Webインターフェース"がありません。クレデンシャルを収集するためのブラウザやインターフェースがないため、まずIDプロバイダに認証を行う必要があります。
2. `id_token`は、取り消すことができません。これは証明書のようなもので、有効期限が短い(数分のみ)必要があるので、数分ごとに新しいトークンを取得しなければならないのは非常に面倒です。
3. Kubernetesダッシュボードへの認証において、`kubectl proxy`コマンドや`id_token`を注入するリバースプロキシーを使う以外に、簡単な方法はありません。
3. Kubernetesダッシュボードへの認証において、`kubectl proxy`コマンドや`id_token`を注入するリバースプロキシを使う以外に、簡単な方法はありません。
#### APIサーバーの設定
@ -402,10 +402,10 @@ POSTボディは、以下の形式になります。
HTTPステータスコードは、追加のエラーコンテキストを提供するために使うことができます。
### 認証プロキシー {#authenticating-proxy}
### 認証プロキシ {#authenticating-proxy}
APIサーバーは、`X-Remote-User`のようにリクエストヘッダの値からユーザーを識別するように設定することができます。
これは、リクエストヘッダの値を設定する認証プロキシーと組み合わせて使用するために設計です。
これは、リクエストヘッダの値を設定する認証プロキシと組み合わせて使用するために設計です。
* `--requestheader-username-headers`: 必須であり、大文字小文字を区別しません。ユーザーのIDをチェックするためのヘッダー名を順番に指定します。値を含む最初のヘッダーが、ユーザー名として使われます。
* `--requestheader-group-headers`: バージョン1.6以降で任意であり、大文字小文字を区別しません。"X-Remote-Group"を推奨します。ユーザーのグループをチェックするためのヘッダー名を順番に指定します。指定されたヘッダーの全ての値が、グループ名として使われます。
@ -450,7 +450,7 @@ extra:
- profile
```
ヘッダーのスプーフィングを防ぐため、認証プロキシーはリクエストヘッダーがチェックされる前に、指定された認証局に対する検証のために有効なクライアント証明書をAPIサーバーへ提示する必要があります。
ヘッダーのスプーフィングを防ぐため、認証プロキシはリクエストヘッダーがチェックされる前に、指定された認証局に対する検証のために有効なクライアント証明書をAPIサーバーへ提示する必要があります。
* `--requestheader-client-ca-file`: 必須です。PEMエンコードされた証明書バンドルです。有効なクライアント証明書を提示し、リクエストヘッダーでユーザー名がチェックされる前に、指定されたファイル内の認証局に対して検証する必要があります。

2
content/ja/docs/reference/command-line-tools-reference/feature-gates/index.md
View File

@ -444,7 +444,7 @@ GAになってからさらなる変更を加えることは現実的ではない
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
- `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
- `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
- `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシ](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
- `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。

2
content/ja/docs/reference/kubectl/_index.md
View File

@ -131,7 +131,7 @@ kubectl config set-context --current --namespace=<namespace-name>
`patch` | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。
`plugin` | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシを実行します。
`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスター上で実行します。

8
content/ja/docs/setup/learning-environment/minikube.md
View File

@ -201,7 +201,7 @@ MinikubeのサポートするKubernetesの機能:
また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/)のインストールも設定します。
{{< note >}}
もしWebプロキシーを通している場合、そのプロキシー情報を`minikube start`コマンドに渡す必要があります:
もしWebプロキシを通している場合、そのプロキシ情報を`minikube start`コマンドに渡す必要があります:
```shell
https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
@ -484,7 +484,7 @@ Minikubeで起動したいアドオンを `~/.minikube/addons` ディレクト
MinikubeはKubernetesとDockerデーモンを含む仮想マシンを作成します。
KubernetesがDockerを使用してコンテナをスケジュールしようとする際、Dockerデーモンはコンテナをプルするために外部ネットワークを必要とする場合があります。
HTTPプロキシーを通している場合には、プロキシー設定をDockerに提供する必要があります。
HTTPプロキシを通している場合には、プロキシ設定をDockerに提供する必要があります。
これを行うには、`minikube start` に必要な環境変数をフラグとして渡します。
例:
@ -494,8 +494,8 @@ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
--docker-env https_proxy=https://$YOURPROXY:PORT
```
仮想マシンのアドレスが192.168.99.100の場合、プロキシーの設定により `kubectl` が直接アクセスできない可能性があります。
このIPアドレスのプロキシー設定を迂回するには、以下のようにno_proxy設定を変更する必要があります。
仮想マシンのアドレスが192.168.99.100の場合、プロキシの設定により `kubectl` が直接アクセスできない可能性があります。
このIPアドレスのプロキシ設定を迂回するには、以下のようにno_proxy設定を変更する必要があります。
```shell
export no_proxy=$no_proxy,$(minikube ip)

4
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -51,10 +51,10 @@ card:
## 必須ポートの確認
Kubernetesのコンポーネントが互いに通信するためには、これらの[必要なポート](/ja/docs/reference/networking/ports-and-protocols/)が開いている必要があります。
netcatなどのツールを使用することで、下記のようにポートが開いているかどうかを確認することが可能です。
[netcat](https://netcat.sourceforge.net)などのツールを使用することで、下記のようにポートが開いているかどうかを確認することが可能です。
```shell
nc 127.0.0.1 6443
nc 127.0.0.1 6443 -v
```
使用するPodネットワークプラグインによっては、特定のポートを開く必要がある場合もあります。

2
content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
View File

@ -46,7 +46,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。
{{< /warning >}}
### コマンドラインプロキシー
### コマンドラインプロキシ
以下のコマンドを実行することで、kubectlコマンドラインツールを使ってダッシュボードにアクセスすることができます:
```

4
content/ja/docs/tasks/administer-cluster/extended-resource-node.md
View File

@ -43,7 +43,7 @@ Host: k8s-master:8080
Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシを実行します。
```shell
kubectl proxy
@ -132,7 +132,7 @@ Host: k8s-master:8080
]
```
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシを実行します。
```shell
kubectl proxy

2
content/ja/docs/tasks/administer-cluster/securing-a-cluster.md
View File

@ -35,7 +35,7 @@ Kubernetesは、クラスター内のすべてのAPI通信がデフォルトでT
例えば、シングルユーザーの小規模なクラスターでは、シンプルな証明書や静的なBearerトークンを使用することができます。
大規模なクラスターでは、ユーザーをグループに細分化できる既存のOIDCまたはLDAPサーバーを統合することができます。
ノード、プロキシー、スケジューラー、ボリュームプラグインなど、インフラの一部であるものも含めて、すべてのAPIクライアントを認証する必要があります。
ノード、プロキシ、スケジューラー、ボリュームプラグインなど、インフラの一部であるものも含めて、すべてのAPIクライアントを認証する必要があります。
これらのクライアントは通常、[service accounts](/docs/reference/access-authn-authz/service-accounts-admin/)であるか、またはx509クライアント証明書を使用しており、クラスター起動時に自動的に作成されるか、クラスターインストールの一部として設定されます。
詳細については、[認証](/ja/docs/reference/access-authn-authz/authentication/)を参照してください。

6
content/ja/docs/tasks/administer-cluster/use-cascading-deletion.md
View File

@ -56,7 +56,7 @@ kubectl delete deployment nginx-deployment --cascade=foreground
**Kubernetes APIを使用する**
1. ローカルプロキシーセッションを開始します:
1. ローカルプロキシセッションを開始します:
```shell
kubectl proxy --port=8080
@ -107,7 +107,7 @@ kubectl delete deployment nginx-deployment --cascade=background
**Kubernetes APIを使用する**
1. ローカルプロキシーセッションを開始します:
1. ローカルプロキシセッションを開始します:
```shell
kubectl proxy --port=8080
@ -151,7 +151,7 @@ kubectl delete deployment nginx-deployment --cascade=orphan
**Kubernetes APIを使用する**
1. ローカルプロキシーセッションを開始します:
1. ローカルプロキシセッションを開始します:
```shell
kubectl proxy --port=8080

6
content/ja/docs/tasks/debug/debug-application/debug-service.md
View File

@ -416,7 +416,7 @@ Endpointsリスト内の各Podは、それぞれの自身のホスト名を返
## kube-proxyは機能しているか？ {#is-the-kube-proxy-working}
ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。
ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。
Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
@ -494,7 +494,7 @@ TCP 10.0.1.175:80 rr
各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。Pod endpointごとに、対応する実サーバーが作成されます。この例では、サービスhostnames(`10.0.1.175:80`)は3つのendpoints(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持っています。
IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
IPVSプロキシは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
#### Userspace mode
@ -525,7 +525,7 @@ curl 10.0.1.175:80
hostnames-632524106-bbpiw
```
もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
もしこれが失敗し、あなたがuserspaceプロキシを使用している場合、プロキシへの直接アクセスを試してみてください。もしiptablesプロキシを使用している場合、このセクションはスキップしてください。
上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。上記の例では"48577"です。このポートに接続してください。

4
content/ja/docs/tasks/debug/debug-cluster/local-debugging.md
View File

@ -7,7 +7,7 @@ content_type: task
Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[実行中のコンテナへのシェルを取得](/ja/docs/tasks/debug/debug-application/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。
`telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。
`telepresence`は、リモートKubernetesクラスターにサービスをプロキシしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。
`telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。
このドキュメントでは、リモートクラスター上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
@ -36,7 +36,7 @@ Kubernetes上でアプリケーションを開発する場合、通常は1つの
そのサービスは、テストやデバッグのために他のサービスへのアクセスを必要とする場合があります。
継続的なデプロイメントパイプラインを使用することも一つの選択肢ですが、最速のデプロイメントパイプラインでさえ、プログラムやデバッグサイクルに遅延が発生します。
既存のデプロイメントとtelepresenceプロキシーを交換するには、`--swap-deployment` オプションを使用します。
既存のデプロイメントとtelepresenceプロキシを交換するには、`--swap-deployment` オプションを使用します。
スワップすることで、ローカルでサービスを実行し、リモートのKubernetesクラスターに接続することができます。
リモートクラスター内のサービスは、ローカルで実行されているインスタンスにアクセスできるようになりました。

10
content/ja/docs/tasks/tools/included/_index.md Normal file
View File

@ -0,0 +1,10 @@
---
title: "Tools Included"
description: "メインのkubectl-installs-*.mdページに含まれるスニペット。"
headless: true
toc_hide: true
_build:
list: never
render: never
publishResources: false
---

14
content/ja/docs/tasks/tools/included/kubectl-convert-overview.md Normal file
View File

@ -0,0 +1,14 @@
---
title: "kubectl-convertの概要"
description: >-
Kubernetes APIのあるバージョンから別のバージョンにマニフェストを変換することができるkubectlプラグイン。
headless: true
_build:
list: never
render: never
publishResources: false
---
異なるAPIバージョン間でマニフェストを変換できる、Kubernetesコマンドラインツール`kubectl`のプラグインです。
これは特に、新しいKubernetesのリリースで、非推奨ではないAPIバージョンにマニフェストを移行する場合に役に立ちます。
詳細については[非推奨ではないAPIへの移行](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis)を参照してください。

15
content/ja/docs/tasks/tools/included/kubectl-whats-next.md Normal file
View File

@ -0,0 +1,15 @@
---
title: "次の項目"
description: "kubectlをインストールした後の次の項目。"
headless: true
_build:
list: never
render: never
publishResources: false
---
* [Minikubeをインストールする](https://minikube.sigs.k8s.io/docs/start/)
* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する。
* [アプリケーションを起動して公開する方法を学ぶ。](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。
* [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する

73
content/ja/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md Normal file
View File

@ -0,0 +1,73 @@
---
title: "bash auto-completion on Linux"
description: "Some optional configuration for bash auto-completion on Linux."
headless: true
_build:
list: never
render: never
publishResources: false
---
### Introduction
The kubectl completion script for Bash can be generated with the command `kubectl completion bash`.
Sourcing the completion script in your shell enables kubectl autocompletion.
However, the completion script depends on
[**bash-completion**](https://github.com/scop/bash-completion),
which means that you have to install this software first
(you can test if you have bash-completion already installed by running `type _init_completion`).
### Install bash-completion
bash-completion is provided by many package managers
(see [here](https://github.com/scop/bash-completion#installation)).
You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
The above commands create `/usr/share/bash-completion/bash_completion`,
which is the main script of bash-completion. Depending on your package manager,
you have to manually source this file in your `~/.bashrc` file.
To find out, reload your shell and run `type _init_completion`.
If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
```bash
source /usr/share/bash-completion/bash_completion
```
Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
### 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:
{{< 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
sudo chmod a+r /etc/bash_completion.d/kubectl
{{< /tab >}}
{{< /tabs >}}
If you have an alias for kubectl, you can extend shell completion to work with that alias:
```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
bash-completion sources all completion scripts in `/etc/bash_completion.d`.
{{< /note >}}
Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
To enable bash autocompletion in current session of shell, source the ~/.bashrc file:
```bash
source ~/.bashrc
```

103
content/ja/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md Normal file
View File

@ -0,0 +1,103 @@
---
title: "macOS上でのbashの自動補完"
description: "macOS上でのbashの自動補完に対するいくつかの補助的な設定。"
headless: true
_build:
list: never
render: never
publishResources: false
---
### はじめに
Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。
シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールしておく必要があります。
{{< warning>}}
bash-completionにはv1とv2の2つのバージョンがあります。
v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。
kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。
**bash-completion v2**と**Bash 4.1以降**が必要になります。
したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。
以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。
{{< /warning >}}
### Bashのアップグレード
ここではBash 4.1以降の使用を前提としています。
Bashのバージョンは下記のコマンドで調べることができます:
```bash
echo $BASH_VERSION
```
バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます:
```bash
brew install bash
```
シェルをリロードし、希望するバージョンを使用していることを確認してください:
```bash
echo $BASH_VERSION $SHELL
```
Homebrewは通常、`/usr/local/bin/bash`にインストールします。
### bash-completionをインストールする
{{< note >}}
前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。
{{< /note >}}
`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。
ない場合は、Homebrewを使用してインストールすることができます:
```bash
brew install bash-completion@2
```
このコマンドの出力で示されたように、`~/.bash_profile`に以下を追記してください:
```bash
brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh"
```
シェルをリロードし、`type _init_completion`を実行してbash-completion v2が正しくインストールされていることを検証してください。
### kubectlの自動補完を有効にする
すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。
これを行うには複数の方法があります:
- 補完スクリプトを`~/.bash_profile`内でsourceする:
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する:
```bash
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- kubectlにエイリアスを張っている場合は、エイリアスでも動作するようにシェルの補完を拡張することができます:
```bash
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
```
- kubectlをHomebrewでインストールした場合([前述](/ja/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)の通り)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょうか。
この場合、なにも操作する必要はありません。
{{< note >}}
Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
{{< /note >}}
どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。

24
content/ja/docs/tasks/tools/included/optional-kubectl-configs-fish.md Normal file
View File

@ -0,0 +1,24 @@
---
title: "fishの自動補完"
description: "fishシェルの自動補完を有効にする補助的な設定。"
headless: true
_build:
list: never
render: never
publishResources: false
---
{{< note >}}
Fishに対する自動補完はkubectl 1.23以降が必要です。
{{< /note >}}
Fishにおけるkubectlの補完スクリプトは`kubectl completion fish`コマンドで生成できます。
シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
すべてのシェルセッションで使用するには、`~/.config/fish/config.fish`に以下を追記してください:
```shell
kubectl completion fish | source
```
シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。

28
content/ja/docs/tasks/tools/included/optional-kubectl-configs-pwsh.md Normal file
View File

@ -0,0 +1,28 @@
---
title: "PowerShellの自動補完"
description: "PowerShellの自動補完に対するいくつかの補助的な設定。"
headless: true
_build:
list: never
render: never
publishResources: false
---
PowerShellにおけるkubectlの補完スクリプトは`kubectl completion powershell`コマンドで生成できます。
すべてのシェルセッションでこれを行うには、次の行を`$PROFILE`ファイルに追加します。
```powershell
kubectl completion powershell | Out-String | Invoke-Expression
```
このコマンドは、PowerShellを起動する度に自動補完のスクリプトを再生成します。
生成されたスクリプトを直接`$PROFILE`ファイルに追加することもできます。
生成されたスクリプトを`$PROFILE`ファイルに追加するためには、PowerShellのプロンプトで次の行を実行します:
```powershell
kubectl completion powershell >> $PROFILE
```
シェルをリロードした後、kubectlの自動補完が機能します。

29
content/ja/docs/tasks/tools/included/optional-kubectl-configs-zsh.md Normal file
View File

@ -0,0 +1,29 @@
---
title: "zshの自動補完"
description: "zshの自動補完に対するいくつかの補助的な設定。"
headless: true
_build:
list: never
render: never
publishResources: false
---
Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマンドで生成できます。
シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
すべてのシェルセッションで使用するには、`~/.zshrc`に以下を追記してください:
```zsh
source <(kubectl completion zsh)
```
kubectlにエイリアスを張っている場合でも、kubectlの自動補完は自動的に機能します。
シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
`2: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください:
```zsh
autoload -Uz compinit
compinit
```

46
content/ja/docs/tasks/tools/included/verify-kubectl.md Normal file
View File

@ -0,0 +1,46 @@
---
title: "kubectlの設定を検証する"
description: "kubectlを検証する方法。"
headless: true
_build:
list: never
render: never
publishResources: false
---
kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)が必要です。
これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。
デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください:
```shell
kubectl cluster-info
```
URLのレスポンスが表示されている場合は、kubectlはクラスターに接続するよう正しく設定されています。
以下のようなメッセージが表示されている場合は、kubectlは正しく設定されていないか、Kubernetesクラスターに接続できていません。
```
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、[Minikube](https://minikube.sigs.k8s.io/docs/start/)などのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
`kubectl cluster-info`がURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください:
```shell
kubectl cluster-info dump
```
### エラーメッセージ'No Auth Provider Found'のトラブルシューティング{#no-auth-provider-found}
Kubernetes 1.26にて、kubectlは以下のクラウドプロバイダーが提供するマネージドKubernetesのビルトイン認証を削除しました。
これらのプロバイダーは、クラウド固有の認証を提供するkubectlプラグインをリリースしています。
手順については以下のプロバイダーのドキュメントを参照してください:
* Azure AKS: [kubelogin plugin](https://azure.github.io/kubelogin/)
* Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl?hl=ja#install_plugin)
(この変更とは関係なく、他の理由で同じエラーメッセージが表示される可能性もあります。)

350
content/ja/docs/tasks/tools/install-kubectl-linux.md Normal file
View File

@ -0,0 +1,350 @@
---
title: Install and Set Up kubectl on Linux
content_type: task
weight: 10
---
## {{% heading "prerequisites" %}}
You must use a kubectl version that is within one minor version difference of
your cluster. For example, a v{{< skew currentVersion >}} client can communicate
with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}},
and v{{< skew currentVersionAddMinor 1 >}} control planes.
Using the latest compatible version of kubectl helps avoid unforeseen issues.
## Install kubectl on Linux
The following methods exist for installing kubectl on Linux:
- [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux)
- [Install using native package management](#install-using-native-package-management)
- [Install using other package management](#install-using-other-package-management)
### Install kubectl binary with curl on Linux
1. Download the latest release with the command:
{{< tabs name="download_binary_linux" >}}
{{< tab name="x86-64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
{{< /tab >}}
{{< tab name="ARM64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl"
{{< /tab >}}
{{< /tabs >}}
{{< note >}}
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)`
portion of the command with the specific version.
For example, to download version {{< skew currentPatchVersion >}} on Linux x86-64, type:
```bash
curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl
```
And for Linux ARM64, type:
```bash
curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/arm64/kubectl
```
{{< /note >}}
1. Validate the binary (optional)
Download the kubectl checksum file:
{{< tabs name="download_checksum_linux" >}}
{{< tab name="x86-64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
{{< /tab >}}
{{< tab name="ARM64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256"
{{< /tab >}}
{{< /tabs >}}
Validate the kubectl binary against the checksum file:
```bash
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
```
If valid, the output is:
```console
kubectl: OK
```
If the check fails, `sha256` exits with nonzero status and prints output similar to:
```console
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Install kubectl
```bash
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
```
{{< note >}}
If you do not have root access on the target system, you can still install
kubectl to the `~/.local/bin` directory:
```bash
chmod +x kubectl
mkdir -p ~/.local/bin
mv ./kubectl ~/.local/bin/kubectl
# and then append (or prepend) ~/.local/bin to $PATH
```
{{< /note >}}
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
```
Or use this for detailed view of version:
```cmd
kubectl version --client --output=yaml
```
### Install using native package management
{{< tabs name="kubectl_install" >}}
{{% tab name="Debian-based distributions" %}}
1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
```shell
sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl
```
2. Download the public signing key for the Kubernetes package repositories. The same signing key is used for all repositories so you can disregard the version in the URL:
```shell
# If the folder `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
```
{{< note >}}
In releases older than Debian 12 and Ubuntu 22.04, folder `/etc/apt/keyrings` does not exist by default, and it should be created before the curl command.
{{< /note >}}
3. Add the appropriate Kubernetes `apt` repository. If you want to use Kubernetes version different than {{< param "version" >}},
replace {{< param "version" >}} with the desired minor version in the command below:
```shell
# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
{{< note >}}
To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/apt/sources.list.d/kubernetes.list` before running `apt-get update` and `apt-get upgrade`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/).
{{< /note >}}
4. Update `apt` package index, then install kubectl:
```shell
sudo apt-get update
sudo apt-get install -y kubectl
```
{{% /tab %}}
{{% tab name="Red Hat-based distributions" %}}
1. Add the Kubernetes `yum` repository. If you want to use Kubernetes version
different than {{< param "version" >}}, replace {{< param "version" >}} with
the desired minor version in the command below.
```bash
# This overwrites any existing configuration in /etc/yum.repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/rpm/repodata/repomd.xml.key
EOF
```
{{< note >}}
To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/yum.repos.d/kubernetes.repo` before running `yum update`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/).
{{< /note >}}
2. Install kubectl using `yum`:
```bash
sudo yum install -y kubectl
```
{{% /tab %}}
{{% tab name="SUSE-based distributions" %}}
1. Add the Kubernetes `zypper` repository. If you want to use Kubernetes version
different than {{< param "version" >}}, replace {{< param "version" >}} with
the desired minor version in the command below.
```bash
# This overwrites any existing configuration in /etc/zypp/repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/rpm/repodata/repomd.xml.key
EOF
```
{{< note >}}
To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/zypp/repos.d/kubernetes.repo`
before running `zypper update`. This procedure is described in more detail in
[Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/).
{{< /note >}}
2. Install kubectl using `zypper`:
```bash
sudo zypper install -y kubectl
```
{{% /tab %}}
{{< /tabs >}}
### Install using other package management
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
If you are on Ubuntu or another Linux distribution that supports the
[snap](https://snapcraft.io/docs/core/install) package manager, kubectl
is available as a [snap](https://snapcraft.io/) application.
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)
package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## Verify kubectl configuration
{{< include "included/verify-kubectl.md" >}}
## Optional kubectl configurations and plugins
### Enable shell autocompletion
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell,
which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
### Install `kubectl convert` plugin
{{< include "included/kubectl-convert-overview.md" >}}
1. Download the latest release with the command:
{{< tabs name="download_convert_binary_linux" >}}
{{< tab name="x86-64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
{{< /tab >}}
{{< tab name="ARM64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert"
{{< /tab >}}
{{< /tabs >}}
1. Validate the binary (optional)
Download the kubectl-convert checksum file:
{{< tabs name="download_convert_checksum_linux" >}}
{{< tab name="x86-64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
{{< /tab >}}
{{< tab name="ARM64" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert.sha256"
{{< /tab >}}
{{< /tabs >}}
Validate the kubectl-convert binary against the checksum file:
```bash
echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
```
If valid, the output is:
```console
kubectl-convert: OK
```
If the check fails, `sha256` exits with nonzero status and prints output similar to:
```console
kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Install kubectl-convert
```bash
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
```
1. Verify plugin is successfully installed
```shell
kubectl convert --help
```
If you do not see an error, it means the plugin is successfully installed.
1. After installing the plugin, clean up the installation files:
```bash
rm kubectl-convert kubectl-convert.sha256
```
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}

300
content/ja/docs/tasks/tools/install-kubectl-macos.md Normal file
View File

@ -0,0 +1,300 @@
---
title: macOS上でのkubectlのインストールおよびセットアップ
content_type: task
weight: 10
---
## {{% heading "prerequisites" %}}
kubectlのバージョンは、クラスターのマイナーバージョンとの差分が1つ以内でなければなりません。
たとえば、クライアントがv{{< skew currentVersion >}}であれば、v{{< skew currentVersionAddMinor -1 >}}、v{{< skew currentVersionAddMinor 0 >}}、v{{< skew currentVersionAddMinor 1 >}}のコントロールプレーンと通信できます。
最新の互換性のあるバージョンのkubectlを使うことで、不測の事態を避けることができるでしょう。
## macOSへkubectlをインストールする{#install-kubectl-on-macos}
macOSへkubectlをインストールするには、次の方法があります:
- [macOSへkubectlをインストールする](#install-kubectl-on-macos)
- [curlを使用してmacOSへkubectlのバイナリをインストールする](#install-kubectl-binary-with-curl-on-macos)
- [Homebrewを使用してmacOSへインストールする](#install-with-homebrew-on-macos)
- [MacPortsを使用してmacOSへインストールする](#install-with-macports-on-macos)
- [kubectlの設定を検証する](#verify-kubectl-configuration)
- [オプションのkubectlの設定とプラグイン](#optional-kubectl-configurations-and-plugins)
- [シェルの自動補完を有効にする](#enable-shell-autocompletion)
- [`kubectl convert`プラグインをインストールする](#install-kubectl-convert-plugin)
### curlを使用してmacOSへkubectlのバイナリをインストールする{#install-kubectl-binary-with-curl-on-macos}
1. 最新リリースをダウンロードしてください:
{{< tabs name="download_binary_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
{{< /tab >}}
{{< tab name="Appleシリコン" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
{{< /tab >}}
{{< /tabs >}}
{{< note >}}
特定のバージョンをダウンロードする場合、コマンドの`$(curl -L -s https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに置き換えてください。
例えば、Intel macOSへ{{< skew currentPatchVersion >}}のバージョンをダウンロードするには、次のコマンドを入力します:
```bash
curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl"
```
Appleシリコン上のmacOSに対しては、次を入力します:
```bash
curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/arm64/kubectl"
```
{{< /note >}}
1. バイナリを検証してください(オプション)
kubectlのチェックサムファイルをダウンロードします:
{{< tabs name="download_checksum_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
{{< /tab >}}
{{< tab name="Appleシリコン" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
{{< /tab >}}
{{< /tabs >}}
チェックサムファイルに対してkubectlバイナリを検証します:
```bash
echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check
```
正しければ、出力は次のようになります:
```console
kubectl: OK
```
チェックに失敗すると、`shasum`は0以外のステータスで終了し、次のような出力を表示します:
```console
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
同じバージョンのバイナリとチェックサムをダウンロードしてください。
{{< /note >}}
1. kubectlバイナリを実行可能にしてください。
```bash
chmod +x ./kubectl
```
1. kubectlバイナリを`PATH`の中に移動させてください。
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
```
{{< note >}}
`/usr/local/bin`がPATH環境変数の中に含まれるようにしてください。
{{< /note >}}
1. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
または、バージョンの詳細を表示するために次を使用します:
```cmd
kubectl version --client --output=yaml
```
1. kubectlをインストールし、検証した後は、チェックサムファイルを削除してください:
```bash
rm kubectl.sha256
```
### Homebrewを使用してmacOSへインストールする{#install-with-homebrew-on-macos}
macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用していれば、Homebrewでkubectlをインストールできます。
1. インストールコマンドを実行してください:
```bash
brew install kubectl
```
または
```bash
brew install kubernetes-cli
```
1. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
### MacPortsを使用してmacOSへインストールする{#install-with-macports-on-macos}
macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使用していれば、MacPortsでkubectlをインストールできます。
1. インストールコマンドを実行してください:
```bash
sudo port selfupdate
sudo port install kubectl
```
1. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
## kubectlの設定を検証する{#verify-kubectl-configuration}
{{< include "included/verify-kubectl.md" >}}
## オプションのkubectlの設定とプラグイン{#optional-kubectl-configurations-and-plugins}
### シェルの自動補完を有効にする{#enable-shell-autocompletion}
kubectlはBash、Zsh、Fish、PowerShellの自動補完を提供しています。
これにより、入力を大幅に削減することができます。
以下にBash、Fish、Zshの自動補完の設定手順を示します。
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
### `kubectl convert`プラグインをインストールする{#install-kubectl-convert-plugin}
{{< include "included/kubectl-convert-overview.md" >}}
1. 次のコマンドを使用して最新リリースをダウンロードしてください:
{{< tabs name="download_convert_binary_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
{{< /tab >}}
{{< tab name="Appleシリコン" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
{{< /tab >}}
{{< /tabs >}}
1. バイナリを検証してください(オプション)
kubectl-convertのチェックサムファイルをダウンロードします:
{{< tabs name="download_convert_checksum_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
{{< /tab >}}
{{< tab name="Appleシリコン" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
{{< /tab >}}
{{< /tabs >}}
チェックサムファイルに対してkubectl-convertバイナリを検証します:
```bash
echo "$(cat kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
```
正しければ、出力は次のようになります:
```console
kubectl-convert: OK
```
チェックに失敗すると、`shasum`は0以外のステータスで終了し、次のような出力を表示します:
```console
kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
同じバージョンのバイナリとチェックサムをダウンロードしてください。
{{< /note >}}
1. kubectl-convertバイナリを実行可能にしてください。
```bash
chmod +x ./kubectl-convert
```
1. kubectl-convertバイナリを`PATH`の中に移動してください。
```bash
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
```
{{< note >}}
`/usr/local/bin`がPATH環境変数の中に含まれるようにしてください。
{{< /note >}}
1. インストールしたバージョンが最新であることを確認してください
```shell
kubectl convert --help
```
何もエラーが表示されない場合は、プラグインが正常にインストールされたことを示しています。
1. プラグインのインストール後、インストールファイルを削除してください:
```bash
rm kubectl-convert kubectl-convert.sha256
```
### macOS上のkubectlをアンインストールする
`kubectl`のインストール方法に応じて、次の方法を使用してください。
### コマンドラインを使用してkubectlをアンインストールする
1. システム上の`kubectl`バイナリの場所を特定してください:
```bash
which kubectl
```
1. `kubectl`バイナリを削除してください:
```bash
sudo rm <path>
```
`<path>`を前のステップの`kubectl`バイナリのパスに置き換えてください。
例えば`sudo rm /usr/local/bin/kubectl`。
### Homebrewを使用してkubectlをアンインストールする
Homebrewを使用して`kubectl`をインストールした場合は、次のコマンドを実行してください:
```bash
brew remove kubectl
```
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}

203
content/ja/docs/tasks/tools/install-kubectl-windows.md Normal file
View File

@ -0,0 +1,203 @@
---
title: Windows上でのkubectlのインストールおよびセットアップ
content_type: task
weight: 10
---
## {{% heading "prerequisites" %}}
kubectlのバージョンは、クラスターのマイナーバージョンとの差分が1つ以内でなければなりません。
たとえば、クライアントがv{{< skew currentVersion >}}であれば、v{{< skew currentVersionAddMinor -1 >}}、v{{< skew currentVersionAddMinor 0 >}}、v{{< skew currentVersionAddMinor 1 >}}のコントロールプレーンと通信できます。
最新の互換性のあるバージョンのkubectlを使うことで、不測の事態を避けることができるでしょう。
## Windowsへkubectlをインストールする
Windowsへkubectlをインストールするには、次の方法があります:
- [curlを使用してWindowsへkubectlのバイナリをインストールする](#install-kubectl-binary-with-curl-on-windows)
- [Chocolatey、Scoopまたはwingetを使用してWindowsへインストールする](#install-nonstandard-package-tools)
### curlを使用してWindowsへkubectlのバイナリをインストールする{#install-kubectl-binary-with-curl-on-windows}
1. 最新の{{< skew currentVersion >}}のパッチリリースをダウンロードしてください:
[kubectl {{< skew currentPatchVersion >}}](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe)。
または、`curl`がインストールされていれば、次のコマンドも使用できます:
```powershell
curl.exe -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe"
```
{{< note >}}
最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)を参照してください。
{{< /note >}}
1. バイナリを検証してください(オプション)
`kubectl`のチェックサムファイルをダウンロードします:
```powershell
curl.exe -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe.sha256"
```
チェックサムファイルに対して`kubectl`バイナリを検証します:
- コマンドプロンプトを使用して、`CertUtil`の出力とダウンロードしたチェックサムファイルを手動で比較します:
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- PowerShellにて`-eq`オペレーターを使用して自動で検証を行い、`True`または`False`で結果を取得します:
```powershell
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
```
1. `kubectl`バイナリのフォルダーを`PATH`環境変数に追加します。
1. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
```cmd
kubectl version --client
```
または、バージョンの詳細を表示するために次を使用します:
```cmd
kubectl version --client --output=yaml
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`を`PATH`に追加します。
Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加された`PATH`の前に追加するか、Docker Desktopの`kubectl`を削除してください。
{{< /note >}}
### Chocolatey、Scoopまたはwingetを使用してWindowsへインストールする{#install-nonstandard-package-tools}
1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラー、[winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/)パッケージマネージャーを使用することもできます。
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
```powershell
choco install kubernetes-cli
```
{{% /tab %}}
{{% tab name="scoop" %}}
```powershell
scoop install kubectl
```
{{% /tab %}}
{{% tab name="winget" %}}
```powershell
winget install -e --id Kubernetes.kubectl
```
{{% /tab %}}
{{< /tabs >}}
1. インストールしたバージョンが最新であることを確認してください:
```powershell
kubectl version --client
```
1. ホームディレクトリへ移動してください:
```powershell
# cmd.exeを使用している場合はcd %USERPROFILE%を実行してください。
cd ~
```
1. `.kube`ディレクトリを作成してください:
```powershell
mkdir .kube
```
1. 作成した`.kube`ディレクトリへ移動してください:
```powershell
cd .kube
```
1. リモートのKubernetesクラスターを使うために、kubectlを設定してください:
```powershell
New-Item config -type file
```
{{< note >}}
Notepadなどの選択したテキストエディターから設定ファイルを編集してください。
{{< /note >}}
## kubectlの設定を検証する
{{< include "included/verify-kubectl.md" >}}
## オプションのkubectlの設定とプラグイン
### シェルの自動補完を有効にする
kubectlはBash、Zsh、Fish、PowerShellの自動補完を提供しています。
これにより、入力を大幅に削減することができます。
以下にPowerShellの自動補完の設定手順を示します。
{{< include "included/optional-kubectl-configs-pwsh.md" >}}
### `kubectl convert`プラグインをインストールする
{{< include "included/kubectl-convert-overview.md" >}}
1. 次のコマンドを使用して最新リリースをダウンロードしてください:
```powershell
curl.exe -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe"
```
1. バイナリを検証してください(オプション)。
`kubectl-convert`のチェックサムファイルをダウンロードします:
```powershell
curl.exe -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
```
チェックサムファイルに対して`kubectl-convert`バイナリを検証します:
- コマンドプロンプトを使用して、`CertUtil`の出力とダウンロードしたチェックサムファイルを手動で比較します:
```cmd
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
```
- PowerShellにて`-eq`オペレーターを使用して自動で検証を行い、`True`または`False`で結果を取得します:
```powershell
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
1. `kubectl-convert`バイナリのフォルダーを`PATH`環境変数に追加します。
1. プラグインが正常にインストールされたことを確認してください。
```shell
kubectl convert --help
```
何もエラーが表示されない場合は、プラグインが正常にインストールされたことを示しています。
1. プラグインのインストール後、インストールファイルを削除してください:
```powershell
del kubectl-convert.exe
del kubectl-convert.exe.sha256
```
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}

509
content/ja/docs/tasks/tools/install-kubectl.md
View File

@ -1,509 +0,0 @@
---
title: kubectlのインストールおよびセットアップ
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: kubectlのインストール
---
<!-- overview -->
Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/kubectl)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlリファレンスドキュメント](/ja/docs/reference/kubectl/)を参照してください。
## {{% heading "prerequisites" %}}
kubectlのバージョンは、クラスターのマイナーバージョンとの差分が1つ以内でなければなりません。たとえば、クライアントがv1.2であれば、v1.1、v1.2、v1.3のマスターで動作するはずです。最新バージョンのkubectlを使うことで、不測の事態を避けることができるでしょう。
<!-- steps -->
## Linuxへkubectlをインストールする {#install-kubectl-on-linux}
### curlを使用してLinuxへkubectlのバイナリをインストールする
1. 次のコマンドにより、最新リリースをダウンロードしてください:
```
curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
```
特定のバージョンをダウンロードする場合、コマンドの`$(curl -LS https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
たとえば、Linuxへ{{< skew currentPatchVersion >}}のバージョンをダウンロードするには、次のコマンドを入力します:
```
curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl
```
2. kubectlバイナリを実行可能にしてください。
```
chmod +x ./kubectl
```
3. バイナリをPATHの中に移動させてください。
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. インストールしたバージョンが最新であることを確認してください:
```
kubectl version --client
```
### ネイティブなパッケージマネージャーを使用してインストールする
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu、DebianまたはHypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
{{< tab name="CentOS、RHELまたはFedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl
{{< /tab >}}
{{< /tabs >}}
### 他のパッケージマネージャーを使用してインストールする
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートする別のLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして使用できます。
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## macOSへkubectlをインストールする {#install-kubectl-on-macos}
### curlを使用してmacOSへkubectlのバイナリをインストールする
1. 最新リリースをダウンロードしてください:
```bash
curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
```
特定のバージョンをダウンロードする場合、コマンドの`$(curl -LS https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
たとえば、macOSへ{{< skew currentPatchVersion >}}のバージョンをダウンロードするには、次のコマンドを入力します:
```bash
curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl
```
2. kubectlバイナリを実行可能にしてください。
```bash
chmod +x ./kubectl
```
3. バイナリをPATHの中に移動させてください。
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
### Homebrewを使用してmacOSへインストールする
macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用していれば、Homebrewでkubectlをインストールすることもできます。
1. インストールコマンドを実行してください:
```bash
brew install kubectl
```
または
```bash
brew install kubernetes-cli
```
2. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
### MacPortsを使用してmacOSへインストールする
macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使用していれば、MacPortsでkubectlをインストールすることもできます。
1. インストールコマンドを実行してください:
```bash
sudo port selfupdate
sudo port install kubectl
```
2. インストールしたバージョンが最新であることを確認してください:
```bash
kubectl version --client
```
## Windowsへkubectlをインストールする {#install-kubectl-on-windows}
### curlを使用してWindowsへkubectlのバイナリをインストールする
1. [こちらのリンク](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< skew currentPatchVersion >}}をダウンロードしてください。
または、`curl`をインストールされていれば、次のコマンドも使用できます:
```bash
curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe
```
最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)を参照してください。
2. バイナリをPATHに追加します
3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
```bash
kubectl version --client
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。
{{< /note >}}
### PSGalleryからPowerShellを使用してインストールする
Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケージマネージャーを使用していれば、Powershellでkubectlをインストールおよびアップデートすることもできます。
1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください):
```powershell
Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
{{< note >}}
`DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。
{{< /note >}}
インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。
2. インストールしたバージョンが最新であることを確認してください:
```powershell
kubectl version --client
```
{{< note >}}
アップデートする際は、手順1に示した2つのコマンドを再実行してください。
{{< /note >}}
### ChocolateyまたはScoopを使用してWindowsへインストールする
1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
```powershell
choco install kubernetes-cli
```
{{% /tab %}}
{{% tab name="scoop" %}}
```powershell
scoop install kubectl
```
{{% /tab %}}
{{< /tabs >}}
2. インストールしたバージョンが最新であることを確認してください:
```powershell
kubectl version --client
```
3. ホームディレクトリへ移動してください:
```powershell
# cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。
cd ~
```
4. `.kube`ディレクトリを作成してください:
```powershell
mkdir .kube
```
5. 作成した`.kube`ディレクトリへ移動してください:
```powershell
cd .kube
```
6. リモートのKubernetesクラスターを使うために、kubectlを設定してください:
```powershell
New-Item config -type file
```
{{< note >}}
Notepadなどの選択したテキストエディターから設定ファイルを編集してください。
{{< /note >}}
## Google Cloud SDKの一部としてダウンロードする
Google Cloud SDKの一部として、kubectlをインストールすることもできます。
1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。
2. `kubectl`のインストールコマンドを実行してください:
```shell
gcloud components install kubectl
```
3. インストールしたバージョンが最新であることを確認してください:
```shell
kubectl version --client
```
## kubectlの設定を検証する
kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください:
```shell
kubectl cluster-info
```
URLのレスポンスが表示されている場合は、kubectlはクラスターに接続するよう正しく設定されています。
以下のようなメッセージが表示されている場合は、kubectlは正しく設定されていないか、Kubernetesクラスターに接続できていません。
```
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
kubectl cluster-infoがURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください:
```shell
kubectl cluster-info dump
```
## kubectlの任意の設定
### シェルの自動補完を有効にする
kubectlはBashおよびZshの自動補完を提供しています。これにより、入力を大幅に削減することができます。
以下にBash(LinuxとmacOSの違いも含む)およびZshの自動補完の設定手順を示します。
{{< tabs name="kubectl_autocompletion" >}}
{{% tab name="LinuxでのBash" %}}
### はじめに
Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります(`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます)。
### bash-completionをインストールする
bash-completionは多くのパッケージマネージャーから提供されています([こちら](https://github.com/scop/bash-completion#installation)を参照してください)。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。
上記のコマンドでbash-completionの主要スクリプトである`/usr/share/bash-completion/bash_completion`が作成されます。パッケージマネージャーによっては、このファイルを`~/.bashrc`にて手動でsourceする必要があります。
これを調べるには、シェルをリロードしてから`type _init_completion`を実行してください。コマンドが成功していればすでに設定済みです。そうでなければ、`~/.bashrc`に以下を追記してください:
```bash
source /usr/share/bash-completion/bash_completion
```
シェルをリロードし、`type _init_completion`を実行してbash-completionが正しくインストールされていることを検証してください。
### kubectlの自動補完を有効にする
すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。これを行うには2つの方法があります:
- 補完スクリプトを`~/.bashrc`内でsourceしてください:
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください:
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
- kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
bash-completionは`/etc/bash_completion.d`内のすべての補完スクリプトをsourceします。
{{< /note >}}
どちらも同様の手法です。シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
{{% /tab %}}
{{% tab name="macOSでのBash" %}}
### はじめに
Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールする必要があります。
{{< warning>}}
bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。
{{< /warning >}}
### bashのアップグレード
ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。
```bash
echo $BASH_VERSION
```
バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。
```bash
brew install bash
```
シェルをリロードし、希望するバージョンを使用していることを確認してください。
```bash
echo $BASH_VERSION $SHELL
```
Homebrewは通常、`/usr/local/bin/bash`にインストールします。
### bash-completionをインストールする
{{< note >}}
前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。
{{< /note >}}
`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます:
```bash
brew install bash-completion@2
```
このコマンドの出力で示されたように、`~/.bash_profile`に以下を追記してください:
```bash
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
シェルをリロードし、`type _init_completion`を実行してbash-completion v2が正しくインストールされていることを検証してください。
### kubectlの自動補完を有効にする
すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。これを行うには複数の方法があります:
- 補完スクリプトを`~/.bash_profile`内でsourceする:
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する:
```bash
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
```bash
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
- kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
{{< note >}}
Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
{{< /note >}}
どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
{{% /tab %}}
{{% tab name="Zsh" %}}
Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
すべてのシェルセッションで使用するには、`~/.zshrc`に以下を追記してください:
```zsh
source <(kubectl completion zsh)
```
kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc
```
シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
`complete:13: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください:
```zsh
autoload -Uz compinit
compinit
```
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
* [Minikubeをインストールする](https://minikube.sigs.k8s.io/docs/start/)
* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する
* [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
* [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する

2
content/ja/docs/tutorials/services/connect-applications-service.md
View File

@ -129,7 +129,7 @@ NAME ADDRESSTYPE PORTS ENDPOINTS AGE
my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s
```
今や、あなたのクラスター内のどのノードからもnginx Serviceに`<CLUSTER-IP>:<PORT>`でcurlを使用してアクセスできるはずです。Service IPは完全に仮想であり、物理的なケーブルで接続されるものではありません。どのように動作しているのか興味があれば、さらなる詳細について[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)を読んでください。
今や、あなたのクラスター内のどのノードからもnginx Serviceに`<CLUSTER-IP>:<PORT>`でcurlを使用してアクセスできるはずです。Service IPは完全に仮想であり、物理的なケーブルで接続されるものではありません。どのように動作しているのか興味があれば、さらなる詳細について[サービスプロキシ](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)を読んでください。
## Serviceへのアクセス

6
content/ja/docs/tutorials/services/source-ip.md
View File

@ -219,7 +219,7 @@ graph LR;
class client plain;
{{</ mermaid >}}
クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。
クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシリクエストだけをプロキシし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。
次のようにして`service.spec.externalTrafficPolicy`フィールドを設定します。
@ -389,9 +389,9 @@ client_address=198.51.100.79
`Type=LoadBalancer`を使用したServiceで送信元IPを保持する機能を提供しているのは一部のクラウドプロバイダだけです。実行しているクラウドプロバイダによっては、以下のように異なる方法でリクエストを満たす場合があります。
1. クライアントとのコネクションをプロキシーが終端し、ノードやエンドポイントとの接続には新しいコネクションが開かれる。このような場合、送信元IPは常にクラウドのロードバランサーのものになり、クライアントのIPにはなりません。
1. クライアントとのコネクションをプロキシが終端し、ノードやエンドポイントとの接続には新しいコネクションが開かれる。このような場合、送信元IPは常にクラウドのロードバランサーのものになり、クライアントのIPにはなりません。
2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。
2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。
1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。

2
content/ja/docs/tutorials/stateless-application/guestbook.md
View File

@ -79,7 +79,7 @@ POD-NAMEの部分を実際のPodの名前に書き換えてください。
### RedisのマスターのServiceを作成する
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
{{% codenew file="application/guestbook/redis-master-service.yaml" %}}

285
content/pt-br/docs/tasks/access-application-cluster/ingress-minikube.md Normal file
View File

@ -0,0 +1,285 @@
---
title: Configurando o Ingress no Minikube com o NGINX Ingress Controller Config
content_type: task
weight: 110
min-kubernetes-server-version: 1.19
---
<!-- overview -->
O [Ingress](/pt-br/docs/concepts/services-networking/ingress/) é um objeto da API que define regras
que permitem acesso externo a serviços em um cluster. Um
[Ingress controller](/docs/concepts/services-networking/ingress-controllers/)
cumpre as regras estabelecidas no Ingress.
Essa página mostra como configurar um Ingress simples que redireciona as requisições para o Service "web" ou "web2" dependendo do URI HTTP.
## {{% heading "prerequisites" %}}
Esse tutorial assume que você está usando `minikube` para rodar um cluster Kubernetes local.
Visite [Install tools](/pt-br/docs/tasks/tools/#minikube) para aprender como instalar o `minikube`.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Se você estiver usando uma versão mais antiga do Kubernetes, veja a documentação para essa versão.
### Criando um cluster minikube
Se você ainda não configurou um cluster local, rode `minikube start` para criar um cluster.
<!-- steps -->
## Ativando o Ingress controller
1. Para ativar o NGINX Ingress controller, rode os seguintes comandos:
```shell
minikube addons enable ingress
```
1. Verifique que o NGINX Ingress controller está rodando
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}
Os pods podem levar até um minuto para estarem rodando corretamente.
{{< /note >}}
O resultado deve ser similar a:
```none
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
```
## Instale uma aplicação hello world
1. Crie um Deployment usando o seguinte comando:
```shell
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
```
O resultado deve ser:
```none
deployment.apps/web created
```
1. Exponha o Deployment:
```shell
kubectl expose deployment web --type=NodePort --port=8080
```
O resultado deve ser:
```none
service/web exposed
```
1. Verifique que o Service está criado e disponível em uma porta do nó:
```shell
kubectl get service web
```
O resultado deve ser similar:
```none
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
```
1. Visite o Service via NodePort:
```shell
minikube service web --url
```
O resultado é similar a:
```none
http://172.17.0.15:31637
```
```shell
curl http://172.17.0.15:31637
```
O resultado é similar a:
```none
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
Você agora pode acessar a aplicação de exemplo através do endereço IP do Minikube e NodePort.
No próximo passo, você irá acessar a aplicação usando o recurso Ingress.
## Criando um Ingress
O manifesto a seguir define um Ingress que envia tráfego para seu Serviço via
`hello-world.info`.
1. crie `example-ingress.yaml` usando o arquivo:
{{% code_sample file="service/networking/example-ingress.yaml" %}}
1. Crie o objeto Ingress rodando o seguinte comando:
```shell
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
```
O resultado deve ser:
```none
ingress.networking.k8s.io/example-ingress created
```
1. Verifique se o endereço IP está configurado:
```shell
kubectl get ingress
```
{{< note >}}
Isso pode demorar alguns minutos.
{{< /note >}}
Você deve ver um endereçco IPv4 na coluna `ADDRESS`; por exemplo:
```none
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress <none> hello-world.info 172.17.0.15 80 38s
```
1. Verifique se o Ingress controller está direcionando o tráfego:
```shell
curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info
```
Você deve ver:
```none
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
Você também pode visitar `hello-world.info` no seu navegador.
* **Opcionalmente**
Procure o endereço IP externo reportado pelo minikube:
```shell
minikube ip
```
Adicione uma linha semelhante à seguinte no final do arquivo `/etc/hosts` no seu computador (você vai precisar de acesso de administrador):
```none
172.17.0.15 hello-world.info
```
{{< note >}}
Altere o endereço IP para corresponder ao resultado de `minikube ip`.
{{< /note >}}
Depois que você fizer essa mudança, seu navegador enviará solicitações da URL `hello-world.info` para o Minikube
## Criando um segundo Deployment
1. Crie outro Deployment usando o seguinte comando:
```shell
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
```
O resultado deve ser:
```none
deployment.apps/web2 created
```
1. Expondo o segundo Deployment:
```shell
kubectl expose deployment web2 --port=8080 --type=NodePort
```
O resultado deve ser:
```none
service/web2 exposed
```
## Edite o Ingress existente {#edit-ingress}
1. Edite o manifesto `example-ingress.yaml` existente, e adicione as seguintes linhas no final:
```yaml
- path: /v2
pathType: Prefix
backend:
service:
name: web2
port:
number: 8080
```
1. Aplique as mudanças:
```shell
kubectl apply -f example-ingress.yaml
```
Você deve ver:
```none
ingress.networking/example-ingress configured
```
## Testando o seu Ingress
1. Acesse a primeira versão da sua aplicação Hello World.
```shell
curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info
```
O resultado deve ser similar a:
```none
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
1. Acesse a segunda versão da sua aplicação Hello World.
```shell
curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info/v2
```
O resultado deve ser similar a:
```none
Hello, world!
Version: 2.0.0
Hostname: web2-75cd47646f-t8cjk
```
{{< note >}}
Se você fez o passo opcional para atualizar o arquivo `/etc/hosts`, você também pode visitar `hello-world.info` e `hello-world.info/v2` do seu navegador.
{{< /note >}}
## {{% heading "whatsnext" %}}
* Leia mais sobre [Ingress](/pt-br/docs/concepts/services-networking/ingress/)
* Leia mais sobre [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* Leia mais sobre [Services](/docs/concepts/services-networking/service/)

18
content/pt-br/examples/service/networking/example-ingress.yaml Normal file
View File

@ -0,0 +1,18 @@
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: hello-world.info
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 8080

2
content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -124,7 +124,7 @@ liveness-exec 1/1 Running 1 1m
## Определение liveness HTTP запроса
Другой вид liveness пробы использует запрос HTTP GET. Ниже представлен файл конфигурации для Pod, который запускает контейнер, основанный на образе `registry.k8s.io/liveness`.
Другой вид liveness пробы использует запрос HTTP GET. Ниже представлен файл конфигурации для Pod, который запускает контейнер, основанный на образе `registry.k8s.io/e2e-test-images/agnhost`.
{{% codenew file="pods/probe/http-liveness.yaml" %}}

4
content/ru/examples/pods/probe/http-liveness.yaml
View File

@ -7,9 +7,9 @@ metadata:
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- /server
- liveness
livenessProbe:
httpGet:
path: /healthz

5
content/zh-cn/docs/concepts/configuration/configmap.md
View File

@ -1,5 +1,8 @@
---
title: ConfigMap
title: ConfigMaps
api_metadata:
- apiVersion: "v1"
kind: "ConfigMap"
content_type: concept
weight: 20
---

6
content/zh-cn/docs/concepts/configuration/secret.md
View File

@ -1,5 +1,8 @@
---
title: Secret
api_metadata:
- apiVersion: "v1"
kind: "Secret"
content_type: concept
feature:
title: Secret 和配置管理
@ -12,6 +15,9 @@ weight: 30
reviewers:
- mikedanese
title: Secrets
api_metadata:
- apiVersion: "v1"
kind: "Secret"
content_type: concept
feature:
title: Secret and configuration management

8
content/zh-cn/docs/concepts/overview/kubernetes-api.md
View File

@ -81,7 +81,7 @@ Kubernetes 使用两种机制来发布这些 API 规范；这两种机制都有
其目的是为可用的资源提供简要总结，不详细说明资源的具体模式。有关资源模式的参考，请参阅 OpenAPI 文档。
<!--
- The [Kubernetes OpenAPI Document](#openapi-specification) provides (full)
- The [Kubernetes OpenAPI Document](#openapi-interface-definition) provides (full)
[OpenAPI v2.0 and 3.0 schemas](https://www.openapis.org/) for all Kubernetes API
endpoints.
The OpenAPI v3 is the preferred method for accessing OpenAPI as it
@ -92,7 +92,7 @@ provides
The data is a complete specification and is significantly larger than that from the
Discovery API.
-->
- [Kubernetes OpenAPI 文档](#openapi-specification)为所有 Kubernetes API 端点提供（完整的）
- [Kubernetes OpenAPI 文档](#openapi-interface-definition)为所有 Kubernetes API 端点提供（完整的）
[OpenAPI v2.0 和 v3.0 模式](https://www.openapis.org/)。OpenAPI v3 是访问 OpenAPI 的首选方法，
因为它提供了更全面和准确的 API 视图。其中包括所有可用的 API 路径，以及每个端点上每个操作所接收和生成的所有资源。
它还包括集群支持的所有可扩展组件。这些数据是完整的规范，比 Discovery API 提供的规范要大得多。
@ -157,14 +157,14 @@ document.
如果没有使用 `Accept` 头指示资源类型，对于 `/api` 和 `/apis` 端点的默认响应将是一个非聚合的发现文档。
<!--
The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-v{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json)
The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json)
for the built-in resources can be found in the Kubernetes GitHub repository.
This Github document can be used as a reference of the base set of the available resources
if a Kubernetes cluster is not available to query.
The endpoint also supports ETag and protobuf encoding.
-->
内置资源的[发现文档](https://github.com/kubernetes/kubernetes/blob/release-v{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json)可以在
内置资源的[发现文档](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json)可以在
Kubernetes GitHub 代码仓库中找到。如果手头没有 Kubernetes 集群可供查询，
此 Github 文档可用作可用资源的基础集合的参考。端点还支持 ETag 和 protobuf 编码。

8
content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -1,5 +1,8 @@
---
title: 名字空间
api_metadata:
- apiVersion: "v1"
kind: "Namespace"
content_type: concept
weight: 45
---
@ -9,6 +12,9 @@ reviewers:
- mikedanese
- thockin
title: Namespaces
api_metadata:
- apiVersion: "v1"
kind: "Namespace"
content_type: concept
weight: 45
-->
@ -16,7 +22,7 @@ weight: 45
<!-- overview -->
<!--
In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced {{< glossary_tooltip text="objects" term_id="object" >}} _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
In Kubernetes, _namespaces_ provide a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced {{< glossary_tooltip text="objects" term_id="object" >}} _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc.)_.
-->
在 Kubernetes 中，**名字空间（Namespace）** 提供一种机制，将同一集群中的资源划分为相互隔离的组。
同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。

19
content/zh-cn/docs/contribute/participate/pr-wranglers.md
View File

@ -30,9 +30,6 @@ SIG Docs 的[批准人（Approver）](/zh-cn/docs/contribute/participate/roles-a
Each day in a week-long shift as PR Wrangler:
- Triage and tag incoming issues daily. See
[Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
for guidelines on how SIG Docs uses metadata.
- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality
and adherence to the [Style](/docs/contribute/style/style-guide/) and
[Content](/docs/contribute/style/content-guide/) guides.
@ -42,9 +39,6 @@ Each day in a week-long shift as PR Wrangler:
在为期一周的轮值期内，PR 管理者要：
- 每天对新增的 Issue 判定和打标签。参见
[对 Issue 进行判定和分类](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
以了解 SIG Docs 如何使用元数据的详细信息。
- 检查[悬决的 PR](https://github.com/kubernetes/website/pulls)
的质量并确保它们符合[样式指南](/zh-cn/docs/contribute/style/style-guide/)和
[内容指南](/zh-cn/docs/contribute/style/content-guide/)要求。
@ -92,6 +86,19 @@ Each day in a week-long shift as PR Wrangler:
- 将风格修复事项标记为 `good first issue` 可以很好地确保向新加入的贡献者分派一些比较简单的任务，
这有助于接纳新的贡献者。
<!--
- Also check for pull requests against the [reference docs generator](https://github.com/kubernetes-sigs/reference-docs) code, and review those (or bring in help).
- Support the [issue wrangler](/docs/contribute/participate/issue-wrangler/) to
triage and tag incoming issues daily.
See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
for guidelines on how SIG Docs uses metadata.
-->
- 同时检查针对[参考文档生成器](https://github.com/kubernetes-sigs/reference-docs)的代码拉取请求，
并对其进行审查（或寻求帮助）。
- 支持[问题管理者](/zh-cn/docs/contribute/participate/issue-wrangler/)每日对新问题进行分类和标记。
参见[分类和组织问题](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
了解 SIG Docs 如何使用元数据。
{{< note >}}
<!--
PR wrangler duties do not apply to localization PRs (non-English PRs).

7
content/zh-cn/docs/setup/best-practices/cluster-large.md
View File

@ -224,16 +224,13 @@ Learn more about [Vertical Pod Autoscaler](https://github.com/kubernetes/autosca
and how you can use it to scale cluster
components, including cluster-critical addons.
* The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
integrates with a number of cloud providers to help you run the right number of
nodes for the level of resource demand in your cluster.
* Read about [cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
-->
* `VerticalPodAutoscaler` 是一种自定义资源，你可以将其部署到集群中，帮助你管理 Pod 的资源请求和资源限制。
了解有关 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)
的更多信息，了解如何用它扩展集群组件（包括对集群至关重要的插件）的信息。
* [集群自动扩缩器](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
与许多云供应商集成在一起，帮助你在你的集群中，按照资源需求级别运行正确数量的节点。
* 阅读关于[集群自动扩缩容](/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/)的信息。
<!--
* The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)

2
content/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
View File

@ -128,6 +128,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
# Replace the value of "containerRuntimeEndpoint" for a different container runtime if needed.
```
-->
```sh
cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
# 将下面的 "systemd" 替换为你的容器运行时所使用的 cgroup 驱动。
@ -194,6 +195,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
# Create temp directories to store files that will end up on other hosts
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
-->
```sh
# 使用你的主机 IP 更新 HOST0、HOST1 和 HOST2 的 IP 地址
export HOST0=10.0.0.6

4
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd.md
View File

@ -93,11 +93,11 @@ to `cri-dockerd`.
## {{% heading "prerequisites" %}}
<!--
* [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install)
* [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/usage/install)
installed and started on each node.
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
-->
* 安装了 [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install)
* 安装了 [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/usage/install)
并且该服务已经在各节点上启动；
* 一个[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)。

4
content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -222,12 +222,12 @@ liveness-exec 1/1 Running 1 1m
## Define a liveness HTTP request
Another kind of liveness probe uses an HTTP GET request. Here is the configuration
file for a Pod that runs a container based on the `registry.k8s.io/liveness` image.
file for a Pod that runs a container based on the `registry.k8s.io/e2e-test-images/agnhost` image.
-->
## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request}
另外一种类型的存活探测方式是使用 HTTP GET 请求。
下面是一个 Pod 的配置文件，其中运行一个基于 `registry.k8s.io/liveness` 镜像的容器。
下面是一个 Pod 的配置文件，其中运行一个基于 `registry.k8s.io/e2e-test-images/agnhost` 镜像的容器。
{{% code_sample file="pods/probe/http-liveness.yaml" %}}

2
content/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md
View File

@ -150,7 +150,7 @@ solutions.
The choice of monitoring platform depends heavily on your needs, budget, and technical resources.
Kubernetes does not recommend any specific metrics pipeline; [many options](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--monitoring) are available.
Your monitoring system should be capable of handling the [OpenMetrics](https://openmetrics.io/) metrics
transmission standard, and needs to chosen to best fit in to your overall design and deployment of
transmission standard and needs to be chosen to best fit into your overall design and deployment of
your infrastructure platform.
-->
将完整的指标管道集成到 Kubernetes 实现中超出了 Kubernetes

9
content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -1044,13 +1044,14 @@ guidelines, which cover this exact use case.
## {{% heading "whatsnext" %}}
<!--
If you configure autoscaling in your cluster, you may also want to consider running a
cluster-level autoscaler such as [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler).
If you configure autoscaling in your cluster, you may also want to consider using
[cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
to ensure you are running the right number of nodes.
For more information on HorizontalPodAutoscaler:
-->
如果你在集群中配置自动扩缩，你可能还需要考虑运行集群级别的自动扩缩器，
例如 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)。
如果你在集群中配置自动扩缩，
你可能还需要考虑使用[集群自动扩缩](/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/)来确保所运行的节点数目合适。
有关 HorizontalPodAutoscaler 的更多信息：

4
content/zh-cn/examples/pods/probe/http-liveness.yaml
View File

@ -7,9 +7,9 @@ metadata:
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- /server
- liveness
livenessProbe:
httpGet:
path: /healthz

5
data/releases/eol.yaml
View File

@ -1,4 +1,9 @@
branches:
- release: "1.26"
finalPatchRelease: "1.26.15"
endOfLifeDate: 2024-02-28
note: >-
1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to [address several Go CVEs](https://groups.google.com/g/golang-dev/c/o1I1Vv8Rfgs/m/Wr8tD1RlAgAJ)
- release: "1.25"
finalPatchRelease: "1.25.16"
endOfLifeDate: 2023-10-28

83
data/releases/schedule.yaml
View File

@ -13,12 +13,15 @@ schedules:
- release: 1.29
releaseDate: 2023-12-13
next:
release: 1.29.3
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-12
release: 1.29.4
cherryPickDeadline: 2024-04-12
targetDate: 2024-04-16
maintenanceModeStartDate: 2024-12-28
endOfLifeDate: 2025-02-28
previousPatches:
- release: 1.29.3
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-12
- release: 1.29.2
cherryPickDeadline: 2024-02-09
targetDate: 2024-02-14
@ -30,12 +33,15 @@ schedules:
- release: 1.28
releaseDate: 2023-08-15
next:
release: 1.28.8
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-12
release: 1.28.9
cherryPickDeadline: 2024-04-12
targetDate: 2024-04-16
maintenanceModeStartDate: 2024-08-28
endOfLifeDate: 2024-10-28
previousPatches:
- release: 1.28.8
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-12
- release: 1.28.7
cherryPickDeadline: 2024-02-09
targetDate: 2024-02-14
@ -68,10 +74,13 @@ schedules:
maintenanceModeStartDate: 2024-04-28
endOfLifeDate: 2024-06-28
next:
release: 1.27.12
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-13
release: 1.27.13
cherryPickDeadline: 2024-04-12
targetDate: 2024-04-16
previousPatches:
- release: 1.27.12
cherryPickDeadline: 2024-03-08
targetDate: 2024-03-13
- release: 1.27.11
cherryPickDeadline: 2024-02-09
targetDate: 2024-02-14
@ -112,59 +121,3 @@ schedules:
- release: 1.27.0
cherryPickDeadline: ""
targetDate: 2023-04-11
- release: 1.26
releaseDate: 2022-12-09
maintenanceModeStartDate: 2023-12-28
endOfLifeDate: 2024-02-28
next:
release: Not Planned
previousPatches:
- release: 1.26.14
cherryPickDeadline: 2024-02-09
targetDate: 2024-02-14
- release: 1.26.13
cherryPickDeadline: 2023-01-12
targetDate: 2024-01-17
- release: 1.26.12
cherryPickDeadline: 2023-12-15
targetDate: 2023-12-20
- release: 1.26.11
cherryPickDeadline: ""
targetDate: 2023-11-14
note: >-
Out of band release to fix [CVE-2023-5528](https://groups.google.com/g/kubernetes-announce/c/c3py6Fw0DTI/m/cScFSdk1BwAJ)
- release: 1.26.10
cherryPickDeadline: 2023-10-13
targetDate: 2023-10-18
- release: 1.26.9
cherryPickDeadline: 2023-09-08
targetDate: 2023-09-13
- release: 1.26.8
cherryPickDeadline: 2023-08-04
targetDate: 2023-08-23
- release: 1.26.7
cherryPickDeadline: 2023-07-14
targetDate: 2023-07-19
- release: 1.26.6
cherryPickDeadline: 2023-06-09
targetDate: 2023-06-14
- release: 1.26.5
cherryPickDeadline: 2023-05-12
targetDate: 2023-05-17
- release: 1.26.4
cherryPickDeadline: 2023-04-07
targetDate: 2023-04-12
- release: 1.26.3
cherryPickDeadline: 2023-03-10
targetDate: 2023-03-15
- release: 1.26.2
cherryPickDeadline: 2023-02-10
targetDate: 2023-02-15
note: >-
[Some container images might be **unsigned** due to a temporary issue with the promotion process](https://groups.google.com/a/kubernetes.io/g/dev/c/MwSx761slM0/m/4ajkeUl0AQAJ)
- release: 1.26.1
cherryPickDeadline: 2023-01-13
targetDate: 2023-01-18
- release: 1.26.0
cherryPickDeadline: ""
targetDate: 2022-12-09

7
layouts/blog/list.html
View File

@ -21,7 +21,12 @@ have blog posts -->
<li class="media mb-4">
<div class="media-body">
<h5 class="mt-0 mb-1"><a href="{{ .RelPermalink }}">{{ .LinkTitle }}</a></h5>
<p class="mb-2 mb-md-3"><small class="text-muted">{{ .Date.Format ($.Param "time_format_blog") }} {{ T "ui_in"}} {{ .CurrentSection.LinkTitle }}</small></p>
<p class="mb-2 mb-md-3">
<small class="text-muted">
{{ with .Params.author }}{{ T "post_byline_by" }} <b>{{ . | markdownify }}</b> |{{ end}}
{{ .Date.Format ($.Param "time_format_blog") }} {{ T "ui_in"}} {{ .CurrentSection.LinkTitle }}
</small>
</p>
{{ partial "featured-image.html" (dict "p" . "w" 250 "h" 125 "class" "float-left mr-3 pt-1 d-none d-md-block") }}
<p class="pt-0 mt-0">{{ .Plain | safeHTML | truncate 250 }}</p>
<p class="pt-0"><a href="{{ .RelPermalink }}">{{ T "ui_read_more"}}</a></p>

2
layouts/partials/docs/api-reference-links.html
View File

@ -28,6 +28,8 @@
<!-- Loop through sections -->
{{- range $apiRefSection := $apiRefSections.Sections -}}
{{- $apiRefDir := $apiRefSection.RelPermalink -}}
{{- $fragmentApiRefDir := split $apiRefDir "/docs" -}}
{{- $apiRefDir := printf "/docs%s" (index ($fragmentApiRefDir) 1) -}}
{{- $apiReferenceFiles := site.GetPage $apiRefDir -}}
<!-- Loop through API reference files -->