diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 0f1c347cfc..c7040f7fa8 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,17 +1,20 @@ ->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> Remember to delete this note before submitting your pull request. -> -> For pull requests on 1.18 Features: set Milestone to 1.18 and Base Branch to dev-1.18 -> -> For pull requests on Chinese localization, set Base Branch to release-1.16 -> Feel free to ask questions in #kubernetes-docs-zh -> -> For pull requests on Korean Localization: set Base Branch to dev-1.16-ko.\ -> -> If you need Help on editing and submitting pull requests, visit: -> https://kubernetes.io/docs/contribute/start/#improve-existing-content. -> -> If you need Help on choosing which branch to use, visit: -> https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use. ->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> + diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index d91daf4ce5..6a04a87b77 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -52,7 +52,6 @@ aliases: - Rajakavitha1 - ryanmcginnis - sftim - - simplytunde - steveperry-53 - tengqm - vineethreddy02 @@ -70,9 +69,7 @@ aliases: - kbhawkey - makoscafee - rajakavitha1 - - ryanmcginnis - sftim - - simplytunde - steveperry-53 - tengqm - xiangpengzhao diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index 55d38ac0a9..2315ae5e94 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -107,7 +107,6 @@ header z-index: 8888 background-color: transparent box-shadow: 0 0 0 transparent - overflow: hidden transition: 0.3s text-align: center @@ -245,6 +244,8 @@ header background-color: white #mainNav + display: none + h5 color: $blue font-weight: normal diff --git a/content/de/community/code-of-conduct.md b/content/de/community/code-of-conduct.md new file mode 100644 index 0000000000..ac0532a1af --- /dev/null +++ b/content/de/community/code-of-conduct.md @@ -0,0 +1,26 @@ +--- +title: Community +layout: basic +cid: community +css: /css/community.css +--- + +
+

Kubernetes Community Code of Conduct

+ +Kubernetes folgt dem +CNCF Verhaltenskodex. +Der Kodex befindet sich weiter unten auf der Seite, wie er auch in +Commit 214585e gefunden werden kann. +Wenn dir auffĂ€llt, dass die hier gezeigte Version nicht mehr aktuell ist, +eröffne bitte ein Issue. + +Wenn dir bei einem Event, einem Meeting, in Slack oder einem anderen +Kommunikationskanal ein Verstoß gegen den Verhaltenskodex auffĂ€llt, wende dich an das Kubernetes Code of Conduct Committee. +Du kannst das Komitee ĂŒber E-Mail erreichen: conduct@kubernetes.io. +Deine AnonymitĂ€t wird geschĂŒtzt. + +
+{{< include "/static/cncf-code-of-conduct.md" >}} +
+
diff --git a/content/de/community/static/README.md b/content/de/community/static/README.md new file mode 100644 index 0000000000..ef8e8d5a3e --- /dev/null +++ b/content/de/community/static/README.md @@ -0,0 +1,2 @@ +The files in this directory have been imported from other sources. Do not +edit them directly, except by replacing them with new versions. \ No newline at end of file diff --git a/content/de/community/static/cncf-code-of-conduct.md b/content/de/community/static/cncf-code-of-conduct.md new file mode 100644 index 0000000000..e94bc7b7fa --- /dev/null +++ b/content/de/community/static/cncf-code-of-conduct.md @@ -0,0 +1,30 @@ + +## CNCF Gemeinschafts-Verhaltenskodex v1.0 + +### Verhaltenskodex fĂŒr Mitwirkende + +Als Mitwirkende und Betreuer dieses Projekts und im Interesse der Förderung einer offenen und einladenden Gemeinschaft verpflichten wir uns dazu, alle Menschen zu respektieren, die durch Berichterstattung, Veröffentlichung von Eigenschaftsanfragen, Aktualisierung der Dokumentation, Einreichung von Pull-Anfragen oder Patches und anderen AktivitĂ€ten einen Beitrag leisten. + +Wir sind bestrebt, die Teilnahme an diesem Projekt fĂŒr alle zu einer belĂ€stigungsfreien Erfahrung zu machen, unabhĂ€ngig von Erfahrungsstand, Geschlecht, geschlechtsspezifischer IdentitĂ€t und Ausdruck, sexueller Orientierung, Behinderung, persönlichem Aussehen, KörpergrĂ¶ĂŸe, Rasse, ethnischer Herkunft, Alter, Religion oder NationalitĂ€t. + +Beispiele fĂŒr unzumutbares Verhalten der Teilnehmer sind: + +- Der Gebrauch von sexualisierter Sprache oder Bildern +- Persönliche Angriffe +- Trolling oder beleidigende/herabwĂŒrdigende Kommentare +- Öffentliche oder private BelĂ€stigungen +- Veröffentlichung privater Informationen anderer, wie z.B. physischer oder elektronischer Adressen, ohne ausdrĂŒckliche Genehmigung +- Anderes unethisches oder unprofessionelles Verhalten. + +Projektbetreuer haben das Recht und die Verantwortung, Kommentare, Commits, Code, Wiki-Bearbeitungen, Probleme und andere BeitrĂ€ge zu entfernen, zu bearbeiten oder abzulehnen, die nicht mit diesem Verhaltenskodex ĂŒbereinstimmen. Mit der Annahme dieses Verhaltenskodex verpflichten sich die Projektbetreuer, diese GrundsĂ€tze fair und konsequent auf jeden Aspekt der Projektleitung anzuwenden. Projektbetreuer, die den Verhaltenskodex nicht befolgen oder durchsetzen, können dauerhaft vom Projektteam ausgeschlossen werden. + +Dieser Verhaltenskodex gilt sowohl innerhalb von ProjektrĂ€umen als auch in öffentlichen RĂ€umen, wenn eine Person das Projekt oder seine Gemeinschaft vertritt. + +FĂ€lle von missbrĂ€uchlichem, belĂ€stigendem oder anderweitig unzumutbarem Verhalten in Kubernetes können gemeldet werden, indem Sie sich an das [Kubernetes Komitee fĂŒr Verhaltenskodex](https://git.k8s.io/community/committee-code-of-conduct) wenden unter . FĂŒr andere Projekte wenden Sie sich bitte an einen CNCF-Projektbetreuer oder an unseren Mediator, Mishi Choudhary . + +Dieser Verhaltenskodex wurde aus dem Contributor Covenant ĂŒbernommen (http://contributor-covenant.org), Version 1.2.0, verfĂŒgbar unter http://contributor-covenant.org/version/1/2/0/ + +### CNCF Verhaltenskodex fĂŒr Veranstaltungen + +FĂŒr CNCF Veranstaltungen gilt der Verhaltenskodex der Linux Foundation, der auf der Veranstaltungsseite verfĂŒgbar ist. Diese ist so konzipiert, dass sie mit der oben genannten Richtlinie kompatibel ist und enthĂ€lt auch weitere Details zur Reaktion auf VorfĂ€lle. diff --git a/content/de/docs/concepts/cluster-administration/addons.md b/content/de/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..4d26b57da8 --- /dev/null +++ b/content/de/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,56 @@ +--- +title: Addons Installieren +content_template: templates/concept +--- + +{{% capture overview %}} + + +Add-Ons erweitern die FunktionalitĂ€t von Kubernetes. + +Diese Seite gibt eine Übersicht ĂŒber einige verfĂŒgbare Add-Ons und verweist auf die entsprechenden Installationsanleitungen. + +Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte. + +{{% /capture %}} + + +{{% capture body %}} + +## Networking und Network Policy + +* [ACI](https://www.github.com/noironetworks/aci-containers) bietet Container-Networking und Network-Security mit Cisco ACI. +* [Calico](https://docs.projectcalico.org/latest/introduction/) ist ein Networking- und Network-Policy-Provider. Calico unterstĂŒtzt eine Reihe von Networking-Optionen, damit Du die richtige fĂŒr deinen Use-Case wĂ€hlen kannst. Dies beinhaltet Non-Overlaying and Overlaying-Networks mit oder ohne BGP. Calico nutzt die gleiche Engine um Network-Policies fĂŒr Hosts, Pods und (falls Du Istio & Envoy benutzt) Anwendungen auf Service-Mesh-Ebene durchzusetzen. +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen. +* [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstĂŒtzt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave. +* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) fĂŒr verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollstĂ€ndig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen. +* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi fĂŒr Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads. +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann. +* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht. +* [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin fĂŒr Mehrfachnetzwerk-UnterstĂŒtzung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusĂ€tzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstĂŒtzen. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt. +* [Romana](http://romana.io) ist eine Layer 3 Network-Lösung fĂŒr Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstĂŒtzt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfĂŒgbar. +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein. + +## Service-Discovery + +* [CoreDNS](https://coredns.io) ist ein flexibler, erweiterbarer DNS-Server der in einem Cluster [installiert](https://github.com/coredns/deployment/tree/master/kubernetes) werden kann und das Cluster-interne DNS fĂŒr Pods bereitzustellen. + +## Visualisierung & Überwachung + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) ist ein Dashboard Web Interface fĂŒr Kubernetes. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) ist ein Tool um Container, Pods, Services usw. Grafisch zu visualieren. Kann in Verbindung mit einem [Weave Cloud Account](https://cloud.weave.works/) genutzt oder selbst gehosted werden. + +## Infrastruktur + +* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) ist ein Add-On um Virtuelle Maschinen in Kubernetes auszufĂŒhren. Wird typischer auf Bare-Metal Clustern eingesetzt. + +## Legacy Add-Ons + +Es gibt einige weitere Add-Ons die in dem abgekĂŒndigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)-Verzeichnis dokumentiert sind. + +Add-Ons die ordentlich gewartet werden dĂŒrfen gerne hier aufgezĂ€hlt werden. Wir freuen uns auf PRs! + +{{% /capture %}} diff --git a/content/de/docs/reference/glossary/etcd.md b/content/de/docs/reference/glossary/etcd.md index e98215a688..147d4ce4bf 100755 --- a/content/de/docs/reference/glossary/etcd.md +++ b/content/de/docs/reference/glossary/etcd.md @@ -15,5 +15,5 @@ tags: -Halten Sie immer einen Sicherungsplan fĂŒr etcds Daten fĂŒr Ihren Kubernetes-Cluster bereit. AusfĂŒhrliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md). +Halten Sie immer einen Sicherungsplan fĂŒr etcds Daten fĂŒr Ihren Kubernetes-Cluster bereit. AusfĂŒhrliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://etcd.io/docs). diff --git a/content/de/docs/tutorials/hello-minikube.md b/content/de/docs/tutorials/hello-minikube.md index 3532b91f39..2e244c3f59 100644 --- a/content/de/docs/tutorials/hello-minikube.md +++ b/content/de/docs/tutorials/hello-minikube.md @@ -145,7 +145,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes ``` Bei Cloud-Anbietern, die Load-Balancer unterstĂŒtzen, wird eine externe IP-Adresse fĂŒr den Zugriff auf den Dienst bereitgestellt. - Bei Minikube ermöglicht der Typ `LoadBalancer` den Dienst ĂŒber den Befehl `minikube service` verfuĂŒgbar zu machen. + Bei Minikube ermöglicht der Typ `LoadBalancer` den Dienst ĂŒber den Befehl `minikube service` verfĂŒgbar zu machen. 3. FĂŒhren Sie den folgenden Befehl aus: diff --git a/content/en/_index.html b/content/en/_index.html index 6882036d47..0be8e71375 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -45,12 +45,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise


- Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020 + Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020



- Attend KubeCon in Shanghai on July 28-30, 2020 + Attend KubeCon in Shanghai on July 28-30, 2020
diff --git a/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md b/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md index 68bd0dcae1..9639e87a53 100644 --- a/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md +++ b/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md @@ -12,21 +12,45 @@ When APIs evolve, the old API is deprecated and eventually removed. The **v1.16** release will stop serving the following deprecated API versions in favor of newer and more stable API versions: -* NetworkPolicy (in the **extensions/v1beta1** API group) - * Migrate to use the **networking.k8s.io/v1** API, available since v1.8. - Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1** API. -* PodSecurityPolicy (in the **extensions/v1beta1** API group) +* NetworkPolicy in the **extensions/v1beta1** API version is no longer served + * Migrate to use the **networking.k8s.io/v1** API version, available since v1.8. + Existing persisted data can be retrieved/updated via the new version. +* PodSecurityPolicy in the **extensions/v1beta1** API version * Migrate to use the **policy/v1beta1** API, available since v1.10. - Existing persisted data can be retrieved/updated via the **policy/v1beta1** API. -* DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the **extensions/v1beta1** and **apps/v1beta2** API groups) - * Migrate to use the **apps/v1** API, available since v1.9. - Existing persisted data can be retrieved/updated via the **apps/v1** API. + Existing persisted data can be retrieved/updated via the new version. +* DaemonSet in the **extensions/v1beta1** and **apps/v1beta2** API versions is no longer served + * Migrate to use the **apps/v1** API version, available since v1.9. + Existing persisted data can be retrieved/updated via the new version. + * Notable changes: + * `spec.templateGeneration` is removed + * `spec.selector` is now required and immutable after creation + * `spec.updateStrategy.type` now defaults to `RollingUpdate` +* Deployment in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served + * Migrate to use the **apps/v1** API version, available since v1.9. + Existing persisted data can be retrieved/updated via the new version. + * Notable changes: + * `spec.rollbackTo` is removed + * `spec.selector` is now required and immutable after creation + * `spec.progressDeadlineSeconds` now defaults to `600` seconds + * `spec.revisionHistoryLimit` now defaults to `10` + * `maxSurge` and `maxUnavailable` now default to `25%` +* StatefulSet in the **apps/v1beta1** and **apps/v1beta2** API versions is no longer served + * Migrate to use the **apps/v1** API version, available since v1.9. + Existing persisted data can be retrieved/updated via the new version. + * Notable changes: + * `spec.selector` is now required and immutable after creation + * `spec.updateStrategy.type` now defaults to `RollingUpdate` +* ReplicaSet in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served + * Migrate to use the **apps/v1** API version, available since v1.9. + Existing persisted data can be retrieved/updated via the new version. + * Notable changes: + * `spec.selector` is now required and immutable after creation The **v1.20** release will stop serving the following deprecated API versions in favor of newer and more stable API versions: -* Ingress (in the **extensions/v1beta1** API group) - * Migrate to use the **networking.k8s.io/v1beta1** API, serving Ingress since v1.14. - Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1beta1** API. +* Ingress in the **extensions/v1beta1** API version will no longer be served + * Migrate to use the **networking.k8s.io/v1beta1** API version, available since v1.14. + Existing persisted data can be retrieved/updated via the new version. # What To Do diff --git a/content/en/blog/_posts/2020-01-21-Docs-Review-2019.md b/content/en/blog/_posts/2020-01-21-Docs-Review-2019.md new file mode 100644 index 0000000000..cf163c4b1e --- /dev/null +++ b/content/en/blog/_posts/2020-01-21-Docs-Review-2019.md @@ -0,0 +1,99 @@ +--- +layout: blog +title: "Reviewing 2019 in Docs" +date: 2020-01-21 +slug: reviewing-2019-in-docs +--- + +**Author:** Zach Corleissen (Cloud Native Computing Foundation) + +Hi, folks! I'm one of the co-chairs for the Kubernetes documentation special interest group (SIG Docs). This blog post is a review of SIG Docs in 2019. Our contributors did amazing work last year, and I want to highlight their successes. + +Although I review 2019 in this post, my goal is to point forward to 2020. I observe some trends in SIG Docs–some good, others troubling. I want to raise visibility before those challenges increase in severity. + +## The good + +There was much to celebrate in SIG Docs in 2019. + +Kubernetes docs started the year with three localizations in progress. By the end of the year, we ended with ten localizations available, four of which (Chinese, French, Japanese, Korean) are reasonably complete. The Korean and French teams deserve special mentions for their contributions to git best practices across all localizations (Korean team) and help bootstrapping other localizations (French team). + +Despite significant transition over the year, SIG Docs [improved its review velocity](https://k8s.devstats.cncf.io/d/44/pr-time-to-approve-and-merge?orgId=1&var-period=w&var-repogroup_name=SIG%20Docs&var-apichange=All&var-size_name=All&var-kind_name=All), with a median review time from PR open to merge of just over 24 hours. + +Issue triage improved significantly in both volume and speed, largely due to the efforts of GitHub users @sftim, @tengqm, and @kbhawkey. + +Doc sprints remain valuable at KubeCon contributor days, introducing new contributors to Kubernetes documentation. + +The docs component of Kubernetes quarterly releases improved over 2019, thanks to iterative playbook improvements from release leads and their teams. + +Site traffic increased over the year. The website ended the year with ~6 million page views per month in December, up from ~5M page views in January. The kubernetes.io website had 851k site visitors in October, a new all-time high. Reader satisfaction [remains general](https://kubernetes.io/blog/2019/10/29/kubernetes-documentation-end-user-survey/). + +We onboarded a new SIG chair: @jimangel, a Cloud Architect at General Motors. Jim was a docs contributor for a year, during which he led the 1.14 docs release, before stepping up as chair. + + + +## The not so good + +While reader satisfaction is decent, **most respondents indicated dissatisfaction with stale content** in every area: concepts, tasks, tutorials, and reference. Additionally, readers requested more diagrams, advanced conceptual content, and code samples—things that technical writers excel at providing. + +SIG Docs continues to solve how best to handle [third-party content](https://github.com/kubernetes/enhancements/pull/1327). **There's too much vendor content on kubernetes.io**, and guidelines for adding or rejecting third-party content remain unclear. The discussion so far has been powerful, including pushback demanding greater collaborative input—a powerful reminder that Kubernetes is in all ways a communal effort. + + +We're in the middle of our third chair transition in 18 months. Each chair transition has been healthy and collegial, but it's still a lot of turnover in a short time. Chairing any open source project is difficult, but especially so with SIG Docs. Chairship of SIG Docs requires a steep learning curve across multiple domains: docs (both written and generated from spec), information architecture, specialized contribution paths (for example, localization), how to run a release cycle, website development, CI/CD, community management, on and on. It's a role that requires multiple people to function successfully without burning people out. Training replacements is time-intensive. + +Perhaps most pressing in the Not So Good category is that SIG Docs currently has only one technical writer dedicated full-time to Kubernetes docs. This has impacts on Kubernetes docs: some obvious, some less so. + +## Impacts of understaffing on Kubernetes docs + + + +If Kubernetes continues through 2020 without more technical writers dedicated to the docs, here's what I see as the most likely possibilities. + +### But first, a disclaimer + +{{< caution >}} + +It is very hard to predict, especially the future. +-Niels Bohr + +{{< /caution >}} + + +Some of my predictions are almost certainly wrong. Any errors are mine alone. + +That said... + +### Effects in 2020 + +Current levels of function aren't self-sustaining. Even with a strong playbook, the release cycle still requires expert support from at least one (and usually two) chairs during every cycle. Without fail, each release breaks in new and unexpected ways, and it requires familiarity and expertise to diagnose and resolve. As chairs continue to cycle—and to be clear, regular transitions are part of a healthy project—we accrue the risks associated with a pool lacking sufficient professional depth and employer support. + +Oddly enough, one of the challenges to staffing is that the docs appear good enough. Based on site analytics and survey responses, readers are pleased with the quality of the docs. When folks visit the site, they generally find what they need and behave like satisfied visitors. + +The danger is that this will change over time: slowly with occasional losses of function, annoying at first, then increasingly critical. The more time passes without adequate staffing, the more difficult and costly fixes will become. + +I suspect this is true because the challenges we face now at decent levels of reader satisfaction are already difficult to fix. API reference generation is complex and brittle; the site's UI is outdated; and our most consistent requests are for more tutorials, advanced concepts, diagrams, and code samples, all of which require ongoing, dedicated time to create. + +**Release support remains strong.** + +The release team continues a solid habit of leaving each successive team with better support than the previous release. This mostly takes the form of iterative improvements to the [docs release playbook](https://github.com/kubernetes/community/tree/master/sig-release#docs-lead), producing better documentation and reducing siloed knowledge. + +**Staleness accelerates.** + +Conceptual content becomes less accurate or relevant as features change or deprecate. Tutorial content degrades for the same reason. + +The content structure will also degrade: the categories of concepts, tasks, and tutorials are legacy categories that may not best fit the needs of current readers, let alone future ones. + +Cruft accumulates for both readers and contributors. Reference docs become increasingly brittle without intervention. + +**Critical knowledge vanishes.** + +As I mentioned previously, SIG Docs has a wide range of functions, some with a steep learning curve. As contributors change roles or jobs, their expertise and availability will diminish or reduce to zero. Contributors with specific knowledge may not be available for consultation, exposing critical vulnerabilities in docs function. Specific examples include reference generation and chair leadership. + +### That's a lot to take in + +It's difficult to strike a balance between the importance of SIG Docs' work to the community and our users, the joy it brings me personally, and the fact that things can't remain as they are without significant negative impacts (eventually). SIG Docs is by no means dying; it's a vibrant community with active contributors doing cool things. It's also a community with some critical knowledge and capacity shortages that can only be remedied with trained, paid staff dedicated to documentation. + +## What the community can do for healthy docs + +Hire technical writers dedicated to Kubernetes docs. Support advanced content creation, not just release docs and incremental feature updates. + +Thanks, and Happy 2020. diff --git a/content/en/blog/_posts/2020-01-21-csi-ephemeral-inline-volumes.md b/content/en/blog/_posts/2020-01-21-csi-ephemeral-inline-volumes.md new file mode 100644 index 0000000000..46570a3e5a --- /dev/null +++ b/content/en/blog/_posts/2020-01-21-csi-ephemeral-inline-volumes.md @@ -0,0 +1,251 @@ +--- +title: CSI Ephemeral Inline Volumes +date: 2020-01-21 +--- + +**Author:** Patrick Ohly (Intel) + +Typically, volumes provided by an external storage driver in +Kubernetes are *persistent*, with a lifecycle that is completely +independent of pods or (as a special case) loosely coupled to the +first pod which uses a volume ([late binding +mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode)). +The mechanism for requesting and defining such volumes in Kubernetes +are [Persistent Volume Claim (PVC) and Persistent Volume +(PV)](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) +objects. Originally, volumes that are backed by a Container Storage Interface +(CSI) driver could only be used via this PVC/PV mechanism. + +But there are also use cases for data volumes whose content and +lifecycle is tied to a pod. For example, a driver might populate a +volume with dynamically created secrets that are specific to the +application running in the pod. Such volumes need to be created +together with a pod and can be deleted as part of pod termination +(*ephemeral*). They get defined as part of the pod spec (*inline*). + +Since Kubernetes 1.15, CSI drivers can also be used for such +*ephemeral inline* volumes. The [CSIInlineVolume feature +gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) +had to be set to enable it in 1.15 because support was still in alpha +state. In 1.16, the feature reached beta state, which typically means +that it is enabled in clusters by default. + +CSI drivers have to be adapted to support this because although two +existing CSI gRPC calls are used (`NodePublishVolume` and `NodeUnpublishVolume`), +the way how they are +used is different and not covered by the CSI spec: for ephemeral +volumes, only `NodePublishVolume` is invoked by `kubelet` when asking +the CSI driver for a volume. All other calls +(like `CreateVolume`, `NodeStageVolume`, etc.) are skipped. The volume +parameters are provided in the pod spec and from there copied into the +`NodePublishVolumeRequest.volume_context` field. There are currently +no standardized parameters; even common ones like size must be +provided in a format that is defined by the CSI driver. Likewise, only +`NodeUnpublishVolume` gets called after the pod has terminated and the +volume needs to be removed. + +Initially, the assumption was that CSI drivers would be specifically +written to provide either persistent or ephemeral volumes. But there +are also drivers which provide storage that is useful in both modes: +for example, [PMEM-CSI](https://github.com/intel/pmem-csi) manages +persistent memory (PMEM), a new kind of local storage that is provided +by [IntelÂź Optaneℱ DC Persistent +Memory](https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html). Such +memory is useful both as persistent data storage (faster than normal SSDs) +and as ephemeral scratch space (higher capacity than DRAM). + +Therefore the support in Kubernetes 1.16 was extended: +* Kubernetes and users can determine which kind of volumes a driver + supports via the `volumeLifecycleModes` field in the [`CSIDriver` + object](https://kubernetes-csi.github.io/docs/csi-driver-object.html#what-fields-does-the-csidriver-object-have). +* Drivers can get information about the volume mode by enabling the + ["pod info on + mount"](https://kubernetes-csi.github.io/docs/pod-info.html) feature + which then will add the new `csi.storage.k8s.io/ephemeral` entry to + the `NodePublishRequest.volume_context`. + +For more information about implementing support of ephemeral inline +volumes in a CSI driver, see the [Kubernetes-CSI +documentation](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html) +and the [original design +document](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190122-csi-inline-volumes.md). + +What follows in this blog post are usage examples based on real drivers +and a summary at the end. + +# Examples + +## [PMEM-CSI](https://github.com/intel/pmem-csi) + +Support for ephemeral inline volumes was added in [release +v0.6.0](https://github.com/intel/pmem-csi/releases/tag/v0.6.0). The +driver can be used on hosts with real IntelÂź Optaneℱ DC Persistent +Memory, on [special machines in +GCE](https://github.com/intel/pmem-csi/blob/v0.6.0/examples/gce.md) or +with hardware emulated by QEMU. The latter is fully [integrated into +the +makefile](https://github.com/intel/pmem-csi/tree/v0.6.0#qemu-and-kubernetes) +and only needs Go, Docker and KVM, so that approach was used for this +example: + +```sh +git clone --branch release-0.6 https://github.com/intel/pmem-csi +cd pmem-csi +TEST_DISTRO=clear TEST_DISTRO_VERSION=32080 TEST_PMEM_REGISTRY=intel make start +``` + +Bringing up the four-node cluster can take a while but eventually should end with: + +``` +The test cluster is ready. Log in with /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm, run kubectl once logged in. +Alternatively, KUBECONFIG=/work/pmem-csi/_work/pmem-govm/kube.config can also be used directly. + +To try out the pmem-csi driver persistent volumes: +... + +To try out the pmem-csi driver ephemeral volumes: + cat deploy/kubernetes-1.17/pmem-app-ephemeral.yaml | /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm kubectl create -f - +``` + +`deploy/kubernetes-1.17/pmem-app-ephemeral.yaml` specifies one volume: + +``` +kind: Pod +apiVersion: v1 +metadata: + name: my-csi-app-inline-volume +spec: + containers: + - name: my-frontend + image: busybox + command: [ "sleep", "100000" ] + volumeMounts: + - mountPath: "/data" + name: my-csi-volume + volumes: + - name: my-csi-volume + csi: + driver: pmem-csi.intel.com + fsType: "xfs" + volumeAttributes: + size: "2Gi" + nsmode: "fsdax" +``` + +Once we have created that pod, we can inspect the result: + +```sh +kubectl describe pods/my-csi-app-inline-volume +``` + +``` +Name: my-csi-app-inline-volume +... +Volumes: + my-csi-volume: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: pmem-csi.intel.com + FSType: xfs + ReadOnly: false + VolumeAttributes: nsmode=fsdax + size=2Gi +``` + +```sh +kubectl exec my-csi-app-inline-volume -- df -h /data +``` + +``` +Filesystem Size Used Available Use% Mounted on +/dev/ndbus0region0fsdax/d7eb073f2ab1937b88531fce28e19aa385e93696 + 1.9G 34.2M 1.8G 2% /data +``` + + +## [Image Populator](https://github.com/kubernetes-csi/csi-driver-image-populator) + +The image populator automatically unpacks a container image and makes +its content available as an ephemeral volume. It's still in +development, but canary images are already available which can be +installed with: + +```sh +kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-csidriverinfo.yaml +kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-daemonset.yaml +``` + +This example pod will run nginx and have it serve data that +comes from the `kfox1111/misc:test` image: + +```sh +kubectl create -f - <> /etc/hosts + +hostnamectl set-hostname master1 +``` +### Install Docker and Kubernetes + +Next, we'll follow the official documents to install docker and Kubernetes using kubeadm. + +Install Docker following the steps from the [container runtime](/docs/setup/production-environment/container-runtimes/) documentation. + +Note that it is a [best practice to use systemd as the cgroup driver](/docs/setup/production-environment/container-runtimes/#cgroup-drivers) for Kubernetes. +If you use an internal container registry, add them to the docker config. +```shell +# Install Docker CE +## Set up the repository +### Install required packages. + +yum install yum-utils device-mapper-persistent-data lvm2 + +### Add Docker repository. + +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## Install Docker CE. + +yum update && yum install docker-ce-18.06.2.ce + +## Create /etc/docker directory. + +mkdir /etc/docker + +# Configure the Docker daemon + +cat > /etc/docker/daemon.json < /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/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +EOF + +# Set SELinux in permissive mode (effectively disabling it) +# Caveat: In a production environment you may not want to disable SELinux, please refer to Kubernetes documents about SELinux +setenforce 0 +sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config + +yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes + +systemctl enable --now kubelet + +cat < /etc/sysctl.d/k8s.conf +net.bridge.bridge-nf-call-ip6tables = 1 +net.bridge.bridge-nf-call-iptables = 1 +EOF +sysctl --system + +# check if br_netfilter module is loaded +lsmod | grep br_netfilter + +# if not, load it explicitly with +modprobe br_netfilter +``` + +The official document about how to create a single control-plane cluster can be found from the [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) documentation. + +We'll largely follow that document but also add additional things for the cloud provider. +To make things more clear, we'll use a `kubeadm-config.yml` for the control-plane node. +In this config we specify to use an external OpenStack cloud provider, and where to find its config. +We also enable storage API in API server's runtime config so we can use OpenStack volumes as persistent volumes in Kubernetes. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta1 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + cloud-provider: "external" +--- +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +kubernetesVersion: "v1.15.1" +apiServer: + extraArgs: + enable-admission-plugins: NodeRestriction + runtime-config: "storage.k8s.io/v1=true" +controllerManager: + extraArgs: + external-cloud-volume-plugin: openstack + extraVolumes: + - name: "cloud-config" + hostPath: "/etc/kubernetes/cloud-config" + mountPath: "/etc/kubernetes/cloud-config" + readOnly: true + pathType: File +networking: + serviceSubnet: "10.96.0.0/12" + podSubnet: "10.224.0.0/16" + dnsDomain: "cluster.local" +``` + +Now we'll create the cloud config, `/etc/kubernetes/cloud-config`, for OpenStack. +Note that the tenant here is the one we created for all Kubernetes VMs in the beginning. +All VMs should be launched in this project/tenant. +In addition you need to create a user in this tenant for Kubernetes to do queries. +The ca-file is the CA root certificate for OpenStack's API endpoint, for example `https://openstack.cloud:5000/v3` +At the time of writing the cloud provider doesn't allow insecure connections (skip CA check). + +```ini +[Global] +region=RegionOne +username=username +password=password +auth-url=https://openstack.cloud:5000/v3 +tenant-id=14ba698c0aec4fd6b7dc8c310f664009 +domain-id=default +ca-file=/etc/kubernetes/ca.pem + +[LoadBalancer] +subnet-id=b4a9a292-ea48-4125-9fb2-8be2628cb7a1 +floating-network-id=bc8a590a-5d65-4525-98f3-f7ef29c727d5 + +[BlockStorage] +bs-version=v2 + +[Networking] +public-network-name=public +ipv6-support-disabled=false +``` + +Next run kubeadm to initiate the control-plane node +```shell +kubeadm init --config=kubeadm-config.yml +``` + +With the initialization completed, copy admin config to .kube +```shell + mkdir -p $HOME/.kube + sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config + sudo chown $(id -u):$(id -g) $HOME/.kube/config +``` + +At this stage, the control-plane node is created but not ready. All the nodes have the taint `node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule` and are waiting to be initialized by the cloud-controller-manager. +```console +# kubectl describe no master1 +Name: master1 +Roles: master +...... +Taints: node-role.kubernetes.io/master:NoSchedule + node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule + node.kubernetes.io/not-ready:NoSchedule +...... +``` +Now deploy the OpenStack cloud controller manager into the cluster, following [using controller manager with kubeadm](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-controller-manager-with-kubeadm.md). + +Create a secret with the cloud-config for the openstack cloud provider. +```shell +kubectl create secret -n kube-system generic cloud-config --from-literal=cloud.conf="$(cat /etc/kubernetes/cloud-config)" --dry-run -o yaml > cloud-config-secret.yaml +kubectl apply -f cloud-config-secret.yaml +``` + +Get the CA certificate for OpenStack API endpoints and put that into `/etc/kubernetes/ca.pem`. + +Create RBAC resources. +```shell +kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/cluster/addons/rbac/cloud-controller-manager-roles.yaml +kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/cluster/addons/rbac/cloud-controller-manager-role-bindings.yaml +``` + +We'll run the OpenStack cloud controller manager as a DaemonSet rather than a pod. +The manager will only run on the control-plane node, so if there are multiple control-plane nodes, multiple pods will be run for high availability. +Create `openstack-cloud-controller-manager-ds.yaml` containing the following manifests, then apply it. + +```yaml +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: openstack-cloud-controller-manager + namespace: kube-system + labels: + k8s-app: openstack-cloud-controller-manager +spec: + selector: + matchLabels: + k8s-app: openstack-cloud-controller-manager + updateStrategy: + type: RollingUpdate + template: + metadata: + labels: + k8s-app: openstack-cloud-controller-manager + spec: + nodeSelector: + node-role.kubernetes.io/master: "" + securityContext: + runAsUser: 1001 + tolerations: + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + - key: node-role.kubernetes.io/master + effect: NoSchedule + - effect: NoSchedule + key: node.kubernetes.io/not-ready + serviceAccountName: cloud-controller-manager + containers: + - name: openstack-cloud-controller-manager + image: docker.io/k8scloudprovider/openstack-cloud-controller-manager:v1.15.0 + args: + - /bin/openstack-cloud-controller-manager + - --v=1 + - --cloud-config=$(CLOUD_CONFIG) + - --cloud-provider=openstack + - --use-service-account-credentials=true + - --address=127.0.0.1 + volumeMounts: + - mountPath: /etc/kubernetes/pki + name: k8s-certs + readOnly: true + - mountPath: /etc/ssl/certs + name: ca-certs + readOnly: true + - mountPath: /etc/config + name: cloud-config-volume + readOnly: true + - mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec + name: flexvolume-dir + - mountPath: /etc/kubernetes + name: ca-cert + readOnly: true + resources: + requests: + cpu: 200m + env: + - name: CLOUD_CONFIG + value: /etc/config/cloud.conf + hostNetwork: true + volumes: + - hostPath: + path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec + type: DirectoryOrCreate + name: flexvolume-dir + - hostPath: + path: /etc/kubernetes/pki + type: DirectoryOrCreate + name: k8s-certs + - hostPath: + path: /etc/ssl/certs + type: DirectoryOrCreate + name: ca-certs + - name: cloud-config-volume + secret: + secretName: cloud-config + - name: ca-cert + secret: + secretName: openstack-ca-cert +``` + +When the controller manager is running, it will query OpenStack to get information about the nodes and remove the taint. In the node info you'll see the VM's UUID in OpenStack. +```console +# kubectl describe no master1 +Name: master1 +Roles: master +...... +Taints: node-role.kubernetes.io/master:NoSchedule + node.kubernetes.io/not-ready:NoSchedule +...... +sage:docker: network plugin is not ready: cni config uninitialized +...... +PodCIDR: 10.224.0.0/24 +ProviderID: openstack:///548e3c46-2477-4ce2-968b-3de1314560a5 + +``` +Now install your favourite CNI and the control-plane node will become ready. + +For example, to install Weave Net, run this command: +```shell +kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" +``` + +Next we'll set up worker nodes. + +Firstly, install docker and kubeadm in the same way as how they were installed in the control-plane node. +To join them to the cluster we need a token and ca cert hash from the output of control-plane node installation. +If it is expired or lost we can recreate it using these commands. + +```shell +# check if token is expired +kubeadm token list + +# re-create token and show join command +kubeadm token create --print-join-command + +``` + +Create `kubeadm-config.yml` for worker nodes with the above token and ca cert hash. +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +discovery: + bootstrapToken: + apiServerEndpoint: 192.168.1.7:6443 + token: 0c0z4p.dnafh6vnmouus569 + caCertHashes: ["sha256:fcb3e956a6880c05fc9d09714424b827f57a6fdc8afc44497180905946527adf"] +kind: JoinConfiguration +nodeRegistration: + kubeletExtraArgs: + cloud-provider: "external" + +``` +apiServerEndpoint is the control-plane node, token and caCertHashes can be taken from the join command printed in the output of 'kubeadm token create' command. + +Run kubeadm and the worker nodes will be joined to the cluster. +```shell +kubeadm join --config kubeadm-config.yml +``` + +At this stage we'll have a working Kubernetes cluster with an external OpenStack cloud provider. +The provider tells Kubernetes about the mapping between Kubernetes nodes and OpenStack VMs. +If Kubernetes wants to attach a persistent volume to a pod, it can find out which OpenStack VM the pod is running on from the mapping, and attach the underlying OpenStack volume to the VM accordingly. + +### Deploy Cinder CSI + +The integration with Cinder is provided by an external Cinder CSI plugin, as described in the [Cinder CSI](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) documentation. + +We'll perform the following steps to install the Cinder CSI plugin. +Firstly, create a secret with CA certs for OpenStack's API endpoints. It is the same cert file as what we use in cloud provider above. +```shell +kubectl create secret -n kube-system generic openstack-ca-cert --from-literal=ca.pem="$(cat /etc/kubernetes/ca.pem)" --dry-run -o yaml > openstack-ca-cert.yaml +kubectl apply -f openstack-ca-cert.yaml +``` +Then create RBAC resources. +```shell +kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/release-1.15/manifests/cinder-csi-plugin/cinder-csi-controllerplugin-rbac.yaml +kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/manifests/cinder-csi-plugin/cinder-csi-nodeplugin-rbac.yaml +``` + +The Cinder CSI plugin includes a controller plugin and a node plugin. +The controller communicates with Kubernetes APIs and Cinder APIs to create/attach/detach/delete Cinder volumes. The node plugin in-turn runs on each worker node to bind a storage device (attached volume) to a pod, and unbind it during deletion. +Create `cinder-csi-controllerplugin.yaml` and apply it to create csi controller. +```yaml +kind: Service +apiVersion: v1 +metadata: + name: csi-cinder-controller-service + namespace: kube-system + labels: + app: csi-cinder-controllerplugin +spec: + selector: + app: csi-cinder-controllerplugin + ports: + - name: dummy + port: 12345 + +--- +kind: StatefulSet +apiVersion: apps/v1 +metadata: + name: csi-cinder-controllerplugin + namespace: kube-system +spec: + serviceName: "csi-cinder-controller-service" + replicas: 1 + selector: + matchLabels: + app: csi-cinder-controllerplugin + template: + metadata: + labels: + app: csi-cinder-controllerplugin + spec: + serviceAccount: csi-cinder-controller-sa + containers: + - name: csi-attacher + image: quay.io/k8scsi/csi-attacher:v1.0.1 + args: + - "--v=5" + - "--csi-address=$(ADDRESS)" + env: + - name: ADDRESS + value: /var/lib/csi/sockets/pluginproxy/csi.sock + imagePullPolicy: "IfNotPresent" + volumeMounts: + - name: socket-dir + mountPath: /var/lib/csi/sockets/pluginproxy/ + - name: csi-provisioner + image: quay.io/k8scsi/csi-provisioner:v1.0.1 + args: + - "--provisioner=csi-cinderplugin" + - "--csi-address=$(ADDRESS)" + env: + - name: ADDRESS + value: /var/lib/csi/sockets/pluginproxy/csi.sock + imagePullPolicy: "IfNotPresent" + volumeMounts: + - name: socket-dir + mountPath: /var/lib/csi/sockets/pluginproxy/ + - name: csi-snapshotter + image: quay.io/k8scsi/csi-snapshotter:v1.0.1 + args: + - "--connection-timeout=15s" + - "--csi-address=$(ADDRESS)" + env: + - name: ADDRESS + value: /var/lib/csi/sockets/pluginproxy/csi.sock + imagePullPolicy: Always + volumeMounts: + - mountPath: /var/lib/csi/sockets/pluginproxy/ + name: socket-dir + - name: cinder-csi-plugin + image: docker.io/k8scloudprovider/cinder-csi-plugin:v1.15.0 + args : + - /bin/cinder-csi-plugin + - "--v=5" + - "--nodeid=$(NODE_ID)" + - "--endpoint=$(CSI_ENDPOINT)" + - "--cloud-config=$(CLOUD_CONFIG)" + - "--cluster=$(CLUSTER_NAME)" + env: + - name: NODE_ID + valueFrom: + fieldRef: + fieldPath: spec.nodeName + - name: CSI_ENDPOINT + value: unix://csi/csi.sock + - name: CLOUD_CONFIG + value: /etc/config/cloud.conf + - name: CLUSTER_NAME + value: kubernetes + imagePullPolicy: "IfNotPresent" + volumeMounts: + - name: socket-dir + mountPath: /csi + - name: secret-cinderplugin + mountPath: /etc/config + readOnly: true + - mountPath: /etc/kubernetes + name: ca-cert + readOnly: true + volumes: + - name: socket-dir + hostPath: + path: /var/lib/csi/sockets/pluginproxy/ + type: DirectoryOrCreate + - name: secret-cinderplugin + secret: + secretName: cloud-config + - name: ca-cert + secret: + secretName: openstack-ca-cert +``` + + +Create `cinder-csi-nodeplugin.yaml` and apply it to create csi node. +```yaml +kind: DaemonSet +apiVersion: apps/v1 +metadata: + name: csi-cinder-nodeplugin + namespace: kube-system +spec: + selector: + matchLabels: + app: csi-cinder-nodeplugin + template: + metadata: + labels: + app: csi-cinder-nodeplugin + spec: + serviceAccount: csi-cinder-node-sa + hostNetwork: true + containers: + - name: node-driver-registrar + image: quay.io/k8scsi/csi-node-driver-registrar:v1.1.0 + args: + - "--v=5" + - "--csi-address=$(ADDRESS)" + - "--kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)" + lifecycle: + preStop: + exec: + command: ["/bin/sh", "-c", "rm -rf /registration/cinder.csi.openstack.org /registration/cinder.csi.openstack.org-reg.sock"] + env: + - name: ADDRESS + value: /csi/csi.sock + - name: DRIVER_REG_SOCK_PATH + value: /var/lib/kubelet/plugins/cinder.csi.openstack.org/csi.sock + - name: KUBE_NODE_NAME + valueFrom: + fieldRef: + fieldPath: spec.nodeName + imagePullPolicy: "IfNotPresent" + volumeMounts: + - name: socket-dir + mountPath: /csi + - name: registration-dir + mountPath: /registration + - name: cinder-csi-plugin + securityContext: + privileged: true + capabilities: + add: ["SYS_ADMIN"] + allowPrivilegeEscalation: true + image: docker.io/k8scloudprovider/cinder-csi-plugin:v1.15.0 + args : + - /bin/cinder-csi-plugin + - "--nodeid=$(NODE_ID)" + - "--endpoint=$(CSI_ENDPOINT)" + - "--cloud-config=$(CLOUD_CONFIG)" + env: + - name: NODE_ID + valueFrom: + fieldRef: + fieldPath: spec.nodeName + - name: CSI_ENDPOINT + value: unix://csi/csi.sock + - name: CLOUD_CONFIG + value: /etc/config/cloud.conf + imagePullPolicy: "IfNotPresent" + volumeMounts: + - name: socket-dir + mountPath: /csi + - name: pods-mount-dir + mountPath: /var/lib/kubelet/pods + mountPropagation: "Bidirectional" + - name: kubelet-dir + mountPath: /var/lib/kubelet + mountPropagation: "Bidirectional" + - name: pods-cloud-data + mountPath: /var/lib/cloud/data + readOnly: true + - name: pods-probe-dir + mountPath: /dev + mountPropagation: "HostToContainer" + - name: secret-cinderplugin + mountPath: /etc/config + readOnly: true + - mountPath: /etc/kubernetes + name: ca-cert + readOnly: true + volumes: + - name: socket-dir + hostPath: + path: /var/lib/kubelet/plugins/cinder.csi.openstack.org + type: DirectoryOrCreate + - name: registration-dir + hostPath: + path: /var/lib/kubelet/plugins_registry/ + type: Directory + - name: kubelet-dir + hostPath: + path: /var/lib/kubelet + type: Directory + - name: pods-mount-dir + hostPath: + path: /var/lib/kubelet/pods + type: Directory + - name: pods-cloud-data + hostPath: + path: /var/lib/cloud/data + type: Directory + - name: pods-probe-dir + hostPath: + path: /dev + type: Directory + - name: secret-cinderplugin + secret: + secretName: cloud-config + - name: ca-cert + secret: + secretName: openstack-ca-cert + +``` +When they are both running, create a storage class for Cinder. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: csi-sc-cinderplugin +provisioner: csi-cinderplugin +``` +Then we can create a PVC with this class. +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myvol +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: csi-sc-cinderplugin + +``` + +When the PVC is created, a Cinder volume is created correspondingly. +```console +# kubectl get pvc +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE +myvol Bound pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad 1Gi RWO csi-sc-cinderplugin 3s + +``` +In OpenStack the volume name will match the Kubernetes persistent volume generated name. In this example it would be: _pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad_ + +Now we can create a pod with the PVC. +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: web +spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + hostPort: 8081 + protocol: TCP + volumeMounts: + - mountPath: "/usr/share/nginx/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myvol +``` +When the pod is running, the volume will be attached to the pod. +If we go back to OpenStack, we can see the Cinder volume is mounted to the worker node where the pod is running on. +```console +# openstack volume show 6b5f3296-b0eb-40cd-bd4f-2067a0d6287f ++--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Field | Value | ++--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| attachments | [{u'server_id': u'1c5e1439-edfa-40ed-91fe-2a0e12bc7eb4', u'attachment_id': u'11a15b30-5c24-41d4-86d9-d92823983a32', u'attached_at': u'2019-07-24T05:02:34.000000', u'host_name': u'compute-6', u'volume_id': u'6b5f3296-b0eb-40cd-bd4f-2067a0d6287f', u'device': u'/dev/vdb', u'id': u'6b5f3296-b0eb-40cd-bd4f-2067a0d6287f'}] | +| availability_zone | nova | +| bootable | false | +| consistencygroup_id | None | +| created_at | 2019-07-24T05:02:18.000000 | +| description | Created by OpenStack Cinder CSI driver | +| encrypted | False | +| id | 6b5f3296-b0eb-40cd-bd4f-2067a0d6287f | +| migration_status | None | +| multiattach | False | +| name | pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad | +| os-vol-host-attr:host | rbd:volumes@rbd#rbd | +| os-vol-mig-status-attr:migstat | None | +| os-vol-mig-status-attr:name_id | None | +| os-vol-tenant-attr:tenant_id | 14ba698c0aec4fd6b7dc8c310f664009 | +| properties | attached_mode='rw', cinder.csi.openstack.org/cluster='kubernetes' | +| replication_status | None | +| size | 1 | +| snapshot_id | None | +| source_volid | None | +| status | in-use | +| type | rbd | +| updated_at | 2019-07-24T05:02:35.000000 | +| user_id | 5f6a7a06f4e3456c890130d56babf591 | ++--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +``` + +### Summary + +In this walk-through, we deployed a Kubernetes cluster on OpenStack VMs and integrated it with OpenStack using an external OpenStack cloud provider. Then on this Kubernetes cluster we deployed Cinder CSI plugin which can create Cinder volumes and expose them in Kubernetes as persistent volumes. diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 2288fdc1c4..cb5b78d55e 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -275,6 +275,12 @@ and do not respect the unschedulable attribute on a node. This assumes that daem the machine even if it is being drained of applications while it prepares for a reboot. {{< /note >}} +{{< caution >}} +`kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service +controller removing the node from any LoadBalancer node target lists it was previously +eligible for, effectively removing incoming load balancer traffic from the cordoned node(s). +{{< /caution >}} + ### Node capacity The capacity of the node (number of cpus and amount of memory) is part of the node object. diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index b82edcd275..75bf1b6a22 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -28,7 +28,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. -* [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. diff --git a/content/en/docs/concepts/cluster-administration/controller-metrics.md b/content/en/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index 57ed5c16d6..0000000000 --- a/content/en/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Controller manager metrics -content_template: templates/concept -weight: 100 ---- - -{{% capture overview %}} -Controller manager metrics provide important insight into the performance and health of -the controller manager. - -{{% /capture %}} - -{{% capture body %}} -## What are controller manager metrics - -Controller manager metrics provide important insight into the performance and health of the controller manager. -These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as -etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used -to gauge the health of a cluster. - -Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack. -These metrics can be used to monitor health of persistent volume operations. - -For example, for GCE these metrics are called: - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## Configuration - - -In a cluster, controller-manager metrics are available from `http://localhost:10252/metrics` -from the host where the controller-manager is running. - -The metrics are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable. - -In a production environment you may want to configure prometheus or some other metrics scraper -to periodically gather these metrics and make them available in some kind of time series database. - -{{% /capture %}} - - diff --git a/content/en/docs/concepts/cluster-administration/monitoring.md b/content/en/docs/concepts/cluster-administration/monitoring.md new file mode 100644 index 0000000000..92b74b6634 --- /dev/null +++ b/content/en/docs/concepts/cluster-administration/monitoring.md @@ -0,0 +1,132 @@ +--- +title: Metrics For The Kubernetes Control Plane +reviewers: +- brancz +- logicalhan +- RainbowMango +content_template: templates/concept +weight: 60 +aliases: +- controller-metrics.md +--- + +{{% capture overview %}} + +System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts. + +Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable. + +{{% /capture %}} + +{{% capture body %}} + +## Metrics in Kubernetes + +In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag. + +Examples of those components: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper +to periodically gather these metrics and make them available in some kind of time series database. + +Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle. + +If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`. +For example: +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: + - get +``` + +## Metric lifecycle + +Alpha metric → Stable metric → Deprecated metric → Hidden metric → Deletion + +Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time. + +Stable metrics can be guaranteed to not change; Specifically, stability means: + +* the metric itself will not be deleted (or renamed) +* the type of metric will not be modified + +Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated. + +Before deprecation: + +``` +# HELP some_counter this counts things +# TYPE some_counter counter +some_counter 0 +``` + +After deprecation: + +``` +# HELP some_counter (Deprecated since 1.15.0) this counts things +# TYPE some_counter counter +some_counter 0 +``` + +Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component. + +Once a metric is deleted, the metric is not published. You cannot change this using an override. + + +## Show Hidden Metrics + +As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release. + +The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release. + +The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy. + +Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion: + +* In release `1.n`, the metric is deprecated, and it can be emitted by default. +* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`. +* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore. + +If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14` + +## Component metrics + +### kube-controller-manager metrics + +Controller manager metrics provide important insight into the performance and health of the controller manager. +These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as +etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used +to gauge the health of a cluster. + +Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack. +These metrics can be used to monitor health of persistent volume operations. + +For example, for GCE these metrics are called: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + +{{% /capture %}} + +{{% capture whatsnext %}} +* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics +* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) +* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) +{{% /capture %}} diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 4b490b827e..399f8b4e22 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -62,6 +62,12 @@ To use priority and preemption in Kubernetes 1.11 and later, follow these steps: Keep reading for more information about these steps. +{{< note >}} +Kubernetes already ships with two PriorityClasses: +`system-cluster-critical` and `system-node-critical`. +These are common classes and are used to [ensure that critical components are always scheduled first](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/). +{{< /note >}} + If you try the feature and then decide to disable it, you must remove the PodPriority command-line flag or set it to `false`, and then restart the API server and scheduler. After the feature is disabled, the existing Pods keep diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 471f5e6c0f..61995234e3 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -10,11 +10,10 @@ feature: weight: 50 --- - {{% capture overview %}} -Kubernetes `secret` objects let you store and manage sensitive information, such -as passwords, OAuth tokens, and ssh keys. Putting this information in a `secret` +Kubernetes Secrets let you store and manage sensitive information, such +as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a {{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information. @@ -25,78 +24,94 @@ is safer and more flexible than putting it verbatim in a ## Overview of Secrets A Secret is an object that contains a small amount of sensitive data such as -a password, a token, or a key. Such information might otherwise be put in a -Pod specification or in an image; putting it in a Secret object allows for -more control over how it is used, and reduces the risk of accidental exposure. +a password, a token, or a key. Such information might otherwise be put in a +Pod specification or in an image. Users can create secrets and the system +also creates some secrets. -Users can create secrets, and the system also creates some secrets. +To use a secret, a Pod needs to reference the secret. +A secret can be used with a Pod in two ways: -To use a secret, a pod needs to reference the secret. -A secret can be used with a pod in two ways: as files in a +- As files in a {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of -its containers, or used by kubelet when pulling images for the pod. +its containers. +- By the kubelet when pulling images for the Pod. ### Built-in Secrets -#### Service Accounts Automatically Create and Attach Secrets with API Credentials +#### Service accounts automatically create and attach Secrets with API credentials Kubernetes automatically creates secrets which contain credentials for -accessing the API and it automatically modifies your pods to use this type of +accessing the API and automatically modifies your Pods to use this type of secret. The automatic creation and use of API credentials can be disabled or overridden -if desired. However, if all you need to do is securely access the apiserver, +if desired. However, if all you need to do is securely access the API server, this is the recommended workflow. -See the [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) documentation for more -information on how Service Accounts work. +See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) +documentation for more information on how service accounts work. ### Creating your own Secrets -#### Creating a Secret Using kubectl create secret +#### Creating a Secret Using `kubectl` -Say that some pods need to access a database. The -username and password that the pods should use is in the files -`./username.txt` and `./password.txt` on your local machine. +Secrets can contain user credentials required by Pods to access a database. +For example, a database connection string +consists of a username and password. You can store the username in a file `./username.txt` +and the password in a file `./password.txt` on your local machine. ```shell -# Create files needed for rest of example. +# Create files needed for the rest of the example. echo -n 'admin' > ./username.txt echo -n '1f2d1e2e67df' > ./password.txt ``` -The `kubectl create secret` command -packages these files into a Secret and creates -the object on the Apiserver. +The `kubectl create secret` command packages these files into a Secret and creates +the object on the API server. ```shell kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt ``` + +The output is similar to: + ``` secret "db-user-pass" created ``` -{{< note >}} -Special characters such as `$`, `\`, `*`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_\(computing\)) and require escaping. In most common shells, the easiest way to escape the password is to surround it with single quotes (`'`). For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: -``` +{{< note >}} +Special characters such as `$`, `\`, `*`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. +In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). +For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: + +```shell kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb' ``` - You do not need to escape special characters in passwords from files (`--from-file`). +You do not need to escape special characters in passwords from files (`--from-file`). {{< /note >}} -You can check that the secret was created like this: +You can check that the secret was created: ```shell kubectl get secrets ``` + +The output is similar to: + ``` NAME TYPE DATA AGE db-user-pass Opaque 2 51s ``` + +You can view a description of the secret: + ```shell kubectl describe secrets/db-user-pass ``` + +The output is similar to: + ``` Name: db-user-pass Namespace: default @@ -112,30 +127,43 @@ username.txt: 5 bytes ``` {{< note >}} -`kubectl get` and `kubectl describe` avoid showing the contents of a secret by -default. -This is to protect the secret from being exposed accidentally to an onlooker, +The commands `kubectl get` and `kubectl describe` avoid showing the contents of a secret by +default. This is to protect the secret from being exposed accidentally to an onlooker, or from being stored in a terminal log. {{< /note >}} -See [decoding a secret](#decoding-a-secret) for how to see the contents of a secret. +See [decoding a secret](#decoding-a-secret) to learn how to view the contents of a secret. -#### Creating a Secret Manually +#### Creating a Secret manually -You can also create a Secret in a file first, in json or yaml format, +You can also create a Secret in a file first, in JSON or YAML format, and then create that object. The -[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) contains two maps: -data and stringData. The data field is used to store arbitrary data, encoded using -base64. The stringData field is provided for convenience, and allows you to provide +[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +contains two maps: +`data` and `stringData`. The `data` field is used to store arbitrary data, encoded using +base64. The `stringData` field is provided for convenience, and allows you to provide secret data as unencoded strings. -For example, to store two strings in a Secret using the data field, convert -them to base64 as follows: +For example, to store two strings in a Secret using the `data` field, convert +the strings to base64 as follows: ```shell echo -n 'admin' | base64 +``` + +The output is similar to: + +``` YWRtaW4= +``` + +```shell echo -n '1f2d1e2e67df' | base64 +``` + +The output is similar to: + +``` MWYyZDFlMmU2N2Rm ``` @@ -157,11 +185,14 @@ Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/ ```shell kubectl apply -f ./secret.yaml ``` + +The output is similar to: + ``` secret "mysecret" created ``` -For certain scenarios, you may wish to use the stringData field instead. This +For certain scenarios, you may wish to use the `stringData` field instead. This field allows you to put a non-base64 encoded string directly into the Secret, and the string will be encoded for you when the Secret is created or updated. @@ -169,7 +200,7 @@ A practical example of this might be where you are deploying an application that uses a Secret to store a configuration file, and you want to populate parts of that configuration file during your deployment process. -If your application uses the following configuration file: +For example, if your application uses the following configuration file: ```yaml apiUrl: "https://my.api.com/api/v1" @@ -177,7 +208,7 @@ username: "user" password: "password" ``` -You could store this in a Secret using the following: +You could store this in a Secret using the following definition: ```yaml apiVersion: v1 @@ -195,14 +226,14 @@ stringData: Your deployment tool could then replace the `{{username}}` and `{{password}}` template variables before running `kubectl apply`. -stringData is a write-only convenience field. It is never output when +The `stringData` field is a write-only convenience field. It is never output when retrieving Secrets. For example, if you run the following command: ```shell kubectl get secret mysecret -o yaml ``` -The output will be similar to: +The output is similar to: ```yaml apiVersion: v1 @@ -218,8 +249,8 @@ data: config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 ``` -If a field is specified in both data and stringData, the value from stringData -is used. For example, the following Secret definition: +If a field, such as `username`, is specified in both `data` and `stringData`, +the value from `stringData` is used. For example, the following Secret definition: ```yaml apiVersion: v1 @@ -233,7 +264,7 @@ stringData: username: administrator ``` -Results in the following secret: +Results in the following Secret: ```yaml apiVersion: v1 @@ -251,26 +282,31 @@ data: Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`. -The keys of data and stringData must consist of alphanumeric characters, +The keys of `data` and `stringData` must consist of alphanumeric characters, '-', '_' or '.'. -**Encoding Note:** The serialized JSON and YAML values of secret data are -encoded as base64 strings. Newlines are not valid within these strings and must -be omitted. When using the `base64` utility on Darwin/macOS users should avoid -using the `-b` option to split long lines. Conversely Linux users *should* add +{{< note >}} +The serialized JSON and YAML values of secret data are +encoded as base64 strings. Newlines are not valid within these strings and must +be omitted. When using the `base64` utility on Darwin/macOS, users should avoid +using the `-b` option to split long lines. Conversely, Linux users *should* add the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if -`-w` option is not available. +the `-w` option is not available. +{{< /note >}} -#### Creating a Secret from Generator -Kubectl supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) -since 1.14. With this new feature, -you can also create a Secret from generators and then apply it to create the object on -the Apiserver. The generators -should be specified in a `kustomization.yaml` inside a directory. +#### Creating a Secret from a generator + +Since Kubernetes v1.14, `kubectl` supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/). Kustomize provides resource Generators to +create Secrets and ConfigMaps. The Kustomize generators should be specified in a +`kustomization.yaml` file inside a directory. After generating the Secret, +you can create the Secret on the API server with `kubectl apply`. + +#### Generating a Secret from files + +You can generate a Secret by defining a `secretGenerator` from the +files ./username.txt and ./password.txt: -For example, to generate a Secret from files `./username.txt` and `./password.txt` ```shell -# Create a kustomization.yaml file with SecretGenerator cat <./kustomization.yaml secretGenerator: - name: db-user-pass @@ -279,20 +315,39 @@ secretGenerator: - password.txt EOF ``` -Apply the kustomization directory to create the Secret object. + +Apply the directory, containing the `kustomization.yaml`, to create the Secret. + ```shell -$ kubectl apply -k . +kubectl apply -k . +``` + +The output is similar to: + +``` secret/db-user-pass-96mffmfh4k created ``` -You can check that the secret was created like this: +You can check that the secret was created: ```shell -$ kubectl get secrets +kubectl get secrets +``` + +The output is similar to: + +``` NAME TYPE DATA AGE db-user-pass-96mffmfh4k Opaque 2 51s +``` -$ kubectl describe secrets/db-user-pass-96mffmfh4k +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` + +The output is similar to: + +``` Name: db-user-pass Namespace: default Labels: @@ -306,11 +361,13 @@ password.txt: 12 bytes username.txt: 5 bytes ``` -For example, to generate a Secret from literals `username=admin` and `password=secret`, -you can specify the secret generator in `kustomization.yaml` as +#### Generating a Secret from string literals + +You can create a Secret by defining a `secretGenerator` +from literals `username=admin` and `password=secret`: + ```shell -# Create a kustomization.yaml file with SecretGenerator -$ cat <./kustomization.yaml +cat <./kustomization.yaml secretGenerator: - name: db-user-pass literals: @@ -318,24 +375,38 @@ secretGenerator: - password=secret EOF ``` -Apply the kustomization directory to create the Secret object. + +Apply the directory, containing the `kustomization.yaml`, to create the Secret. + ```shell -$ kubectl apply -k . +kubectl apply -k . +``` + +The output is similar to: + +``` secret/db-user-pass-dddghtt9b5 created ``` + {{< note >}} -The generated Secrets name has a suffix appended by hashing the contents. This ensures that a new -Secret is generated each time the contents is modified. +When a Secret is generated, the Secret name is created by hashing +the Secret data and appending this value to the name. This ensures that +a new Secret is generated each time the data is modified. {{< /note >}} #### Decoding a Secret -Secrets can be retrieved via the `kubectl get secret` command. For example, to retrieve the secret created in the previous section: +Secrets can be retrieved by running `kubectl get secret`. +For example, you can view the Secret created in the previous section by +running the following command: ```shell kubectl get secret mysecret -o yaml ``` -``` + +The output is similar to: + +```yaml apiVersion: v1 kind: Secret metadata: @@ -350,26 +421,29 @@ data: password: MWYyZDFlMmU2N2Rm ``` -Decode the password field: +Decode the `password` field: ```shell echo 'MWYyZDFlMmU2N2Rm' | base64 --decode ``` + +The output is similar to: + ``` 1f2d1e2e67df ``` #### Editing a Secret -An existing secret may be edited with the following command: +An existing Secret may be edited with the following command: ```shell kubectl edit secrets mysecret ``` -This will open the default configured editor and allow for updating the base64 encoded secret values in the `data` field: +This will open the default configured editor and allow for updating the base64 encoded Secret values in the `data` field: -``` +```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. @@ -392,23 +466,23 @@ type: Opaque ## Using Secrets -Secrets can be mounted as data volumes or be exposed as +Secrets can be mounted as data volumes or exposed as {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} -to be used by a container in a pod. They can also be used by other parts of the -system, without being directly exposed to the pod. For example, they can hold +to be used by a container in a Pod. Secrets can also be used by other parts of the +system, without being directly exposed to the Pod. For example, Secrets can hold credentials that other parts of the system should use to interact with external systems on your behalf. -### Using Secrets as Files from a Pod +### Using Secrets as files from a Pod To consume a Secret in a volume in a Pod: -1. Create a secret or use an existing one. Multiple pods can reference the same secret. -1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].secret.secretName` field equal to the name of the secret object. -1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear. -1. Modify your image and/or command line so that the program looks for files in that directory. Each key in the secret `data` map becomes the filename under `mountPath`. +1. Create a secret or use an existing one. Multiple Pods can reference the same secret. +1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].secret.secretName` field equal to the name of the Secret object. +1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear. +1. Modify your image or command line so that the program looks for files in that directory. Each key in the secret `data` map becomes the filename under `mountPath`. -This is an example of a pod that mounts a secret in a volume: +This is an example of a Pod that mounts a Secret in a volume: ```yaml apiVersion: v1 @@ -429,17 +503,17 @@ spec: secretName: mysecret ``` -Each secret you want to use needs to be referred to in `.spec.volumes`. +Each Secret you want to use needs to be referred to in `.spec.volumes`. -If there are multiple containers in the pod, then each container needs its -own `volumeMounts` block, but only one `.spec.volumes` is needed per secret. +If there are multiple containers in the Pod, then each container needs its +own `volumeMounts` block, but only one `.spec.volumes` is needed per Secret. You can package many files into one secret, or use many secrets, whichever is convenient. -**Projection of secret keys to specific paths** +#### Projection of Secret keys to specific paths -We can also control the paths within the volume where Secret keys are projected. -You can use `.spec.volumes[].secret.items` field to change target path of each key: +You can also control the paths within the volume where Secret keys are projected. +You can use the `.spec.volumes[].secret.items` field to change the target path of each key: ```yaml apiVersion: v1 @@ -466,17 +540,17 @@ spec: What will happen: * `username` secret is stored under `/etc/foo/my-group/my-username` file instead of `/etc/foo/username`. -* `password` secret is not projected +* `password` secret is not projected. If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected. To consume all keys from the secret, all of them must be listed in the `items` field. All listed keys must exist in the corresponding secret. Otherwise, the volume is not created. -**Secret files permissions** +#### Secret files permissions -You can also specify the permission mode bits files part of a secret will have. -If you don't specify any, `0644` is used by default. You can specify a default -mode for the whole secret volume and override per key if needed. +You can set the file access permission bits for a single Secret key. +If you don't specify any permissions, `0644` is used by default. +You can also set a default mode for the entire Secret volume and override per key if needed. For example, you can specify a default mode like this: @@ -503,11 +577,11 @@ Then, the secret will be mounted on `/etc/foo` and all the files created by the secret volume mount will have permission `0400`. Note that the JSON spec doesn't support octal notation, so use the value 256 for -0400 permissions. If you use yaml instead of json for the pod, you can use octal +0400 permissions. If you use YAML instead of JSON for the Pod, you can use octal notation to specify permissions in a more natural way. You can also use mapping, as in the previous example, and specify different -permission for different files like this: +permissions for different files like this: ```yaml apiVersion: v1 @@ -538,16 +612,18 @@ in decimal notation. Note that this permission value might be displayed in decimal notation if you read it later. -**Consuming Secret Values from Volumes** +#### Consuming Secret values from volumes Inside the container that mounts a secret volume, the secret keys appear as -files and the secret values are base-64 decoded and stored inside these files. -This is the result of commands -executed inside the container from the example above: +files and the secret values are base64 decoded and stored inside these files. +This is the result of commands executed inside the container from the example above: ```shell ls /etc/foo/ ``` + +The output is similar to: + ``` username password @@ -556,14 +632,19 @@ password ```shell cat /etc/foo/username ``` + +The output is similar to: + ``` admin ``` - ```shell cat /etc/foo/password ``` + +The output is similar to: + ``` 1f2d1e2e67df ``` @@ -571,19 +652,19 @@ cat /etc/foo/password The program in a container is responsible for reading the secrets from the files. -**Mounted Secrets are updated automatically** +#### Mounted Secrets are updated automatically -When a secret being already consumed in a volume is updated, projected keys are eventually updated as well. -Kubelet is checking whether the mounted secret is fresh on every periodic sync. -However, it is using its local cache for getting the current value of the Secret. -The type of the cache is configurable using the (`ConfigMapAndSecretChangeDetectionStrategy` field in -[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)). -It can be either propagated via watch (default), ttl-based, or simply redirecting -all requests to directly kube-apiserver. +When a secret currently consumed in a volume is updated, projected keys are eventually updated as well. +The kubelet checks whether the mounted secret is fresh on every periodic sync. +However, the kubelet uses its local cache for getting the current value of the Secret. +The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in +the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). +A Secret can be either propagated by watch (default), ttl-based, or simply redirecting +all requests directly to the API server. As a result, the total delay from the moment when the Secret is updated to the moment -when new keys are projected to the Pod can be as long as kubelet sync period + cache -propagation delay, where cache propagation delay depends on the chosen cache type -(it equals to watch propagation delay, ttl of cache, or zero corespondingly). +when new keys are projected to the Pod can be as long as the kubelet sync period + cache +propagation delay, where the cache propagation delay depends on the chosen cache type +(it equals to watch propagation delay, ttl of cache, or zero correspondingly). {{< note >}} A container using a Secret as a @@ -591,16 +672,16 @@ A container using a Secret as a Secret updates. {{< /note >}} -### Using Secrets as Environment Variables +### Using Secrets as environment variables To use a secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}} -in a pod: +in a Pod: -1. Create a secret or use an existing one. Multiple pods can reference the same secret. -1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[].valueFrom.secretKeyRef`. -1. Modify your image and/or command line so that the program looks for values in the specified environment variables +1. Create a secret or use an existing one. Multiple Pods can reference the same secret. +1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[].valueFrom.secretKeyRef`. +1. Modify your image and/or command line so that the program looks for values in the specified environment variables. -This is an example of a pod that uses secrets from environment variables: +This is an example of a Pod that uses secrets from environment variables: ```yaml apiVersion: v1 @@ -625,46 +706,55 @@ spec: restartPolicy: Never ``` -**Consuming Secret Values from Environment Variables** +#### Consuming Secret Values from environment variables Inside a container that consumes a secret in an environment variables, the secret keys appear as -normal environment variables containing the base-64 decoded values of the secret data. +normal environment variables containing the base64 decoded values of the secret data. This is the result of commands executed inside the container from the example above: ```shell echo $SECRET_USERNAME ``` + +The output is similar to: + ``` admin ``` + ```shell echo $SECRET_PASSWORD ``` + +The output is similar to: + ``` 1f2d1e2e67df ``` ### Using imagePullSecrets -An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry -password to the Kubelet so it can pull a private image on behalf of your Pod. +The `imagePullSecrets` field is a list of references to secrets in the same namespace. +You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry +password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod. +See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field. -**Manually specifying an imagePullSecret** +#### Manually specifying an imagePullSecret -Use of imagePullSecrets is described in the [images documentation](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +You can learn how to specify `ImagePullSecrets` from the [container images documentation](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). -### Arranging for imagePullSecrets to be Automatically Attached +### Arranging for imagePullSecrets to be automatically attached -You can manually create an imagePullSecret, and reference it from -a serviceAccount. Any pods created with that serviceAccount -or that default to use that serviceAccount, will get their imagePullSecret +You can manually create `imagePullSecrets`, and reference it from +a ServiceAccount. Any Pods created with that ServiceAccount +or created with that ServiceAccount by default, will get their `imagePullSecrets` field set to that of the service account. See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. -### Automatic Mounting of Manually Created Secrets +### Automatic mounting of manually created Secrets -Manually created secrets (e.g. one containing a token for accessing a github account) +Manually created secrets (for example, one containing a token for accessing a GitHub account) can be automatically attached to pods based on their service account. See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process. @@ -673,76 +763,83 @@ See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data- ### Restrictions Secret volume sources are validated to ensure that the specified object -reference actually points to an object of type `Secret`. Therefore, a secret -needs to be created before any pods that depend on it. +reference actually points to an object of type Secret. Therefore, a secret +needs to be created before any Pods that depend on it. -Secret API objects reside in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. -They can only be referenced by pods in that same namespace. +Secret resources reside in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Secrets can only be referenced by Pods in that same namespace. -Individual secrets are limited to 1MiB in size. This is to discourage creation -of very large secrets which would exhaust apiserver and kubelet memory. -However, creation of many smaller secrets could also exhaust memory. More +Individual secrets are limited to 1MiB in size. This is to discourage creation +of very large secrets which would exhaust the API server and kubelet memory. +However, creation of many smaller secrets could also exhaust memory. More comprehensive limits on memory usage due to secrets is a planned feature. -Kubelet only supports use of secrets for Pods it gets from the API server. -This includes any pods created using kubectl, or indirectly via a replication -controller. It does not include pods created via the kubelets +The kubelet only supports the use of secrets for Pods where the secrets +are obtained from the API server. +This includes any Pods created using `kubectl`, or indirectly via a replication +controller. It does not include Pods created as a result of the kubelet `--manifest-url` flag, its `--config` flag, or its REST API (these are -not common ways to create pods.) +not common ways to create Pods.) -Secrets must be created before they are consumed in pods as environment -variables unless they are marked as optional. References to Secrets that do -not exist will prevent the pod from starting. +Secrets must be created before they are consumed in Pods as environment +variables unless they are marked as optional. References to secrets that do +not exist will prevent the Pod from starting. -References via `secretKeyRef` to keys that do not exist in a named Secret -will prevent the pod from starting. +References (`secretKeyRef` field) to keys that do not exist in a named Secret +will prevent the Pod from starting. -Secrets used to populate environment variables via `envFrom` that have keys +Secrets used to populate environment variables by the `envFrom` field that have keys that are considered invalid environment variable names will have those keys -skipped. The pod will be allowed to start. There will be an event whose +skipped. The Pod will be allowed to start. There will be an event whose reason is `InvalidVariableNames` and the message will contain the list of invalid keys that were skipped. The example shows a pod which refers to the -default/mysecret that contains 2 invalid keys, 1badkey and 2alsobad. +default/mysecret that contains 2 invalid keys: `1badkey` and `2alsobad`. ```shell kubectl get events ``` + +The output is similar to: + ``` LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. ``` -### Secret and Pod Lifetime interaction +### Secret and Pod lifetime interaction -When a pod is created via the API, there is no check whether a referenced -secret exists. Once a pod is scheduled, the kubelet will try to fetch the -secret value. If the secret cannot be fetched because it does not exist or -because of a temporary lack of connection to the API server, kubelet will -periodically retry. It will report an event about the pod explaining the -reason it is not started yet. Once the secret is fetched, the kubelet will -create and mount a volume containing it. None of the pod's containers will -start until all the pod's volumes are mounted. +When a Pod is created by calling the Kubernetes API, there is no check if a referenced +secret exists. Once a Pod is scheduled, the kubelet will try to fetch the +secret value. If the secret cannot be fetched because it does not exist or +because of a temporary lack of connection to the API server, the kubelet will +periodically retry. It will report an event about the Pod explaining the +reason it is not started yet. Once the secret is fetched, the kubelet will +create and mount a volume containing it. None of the Pod's containers will +start until all the Pod's volumes are mounted. ## Use cases ### Use-Case: Pod with ssh keys -Create a kustomization.yaml with SecretGenerator containing some ssh keys: +Create a secret containing some ssh keys: ```shell kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub ``` +The output is similar to: + ``` secret "ssh-key-secret" created ``` +You can also create a `kustomization.yaml` with a `secretGenerator` field containing ssh keys. + {{< caution >}} -Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised. +Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke this account if the users are compromised. {{< /caution >}} - -Now we can create a pod which references the secret with the ssh key and +Now you can create a Pod which references the secret with the ssh key and consumes it in a volume: ```yaml @@ -768,7 +865,7 @@ spec: When the container's command runs, the pieces of the key will be available in: -```shell +``` /etc/secret-volume/ssh-publickey /etc/secret-volume/ssh-privatekey ``` @@ -777,15 +874,19 @@ The container is then free to use the secret data to establish an ssh connection ### Use-Case: Pods with prod / test credentials -This example illustrates a pod which consumes a secret containing prod -credentials and another pod which consumes a secret with test environment +This example illustrates a Pod which consumes a secret containing production +credentials and another Pod which consumes a secret with test environment credentials. -Make the kustomization.yaml with SecretGenerator +You can create a `kustomization.yaml` with a `secretGenerator` field or run +`kubectl create secret`. ```shell kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` + +The output is similar to: + ``` secret "prod-db-secret" created ``` @@ -793,23 +894,29 @@ secret "prod-db-secret" created ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` + +The output is similar to: + ``` secret "test-db-secret" created ``` -{{< note >}} -Special characters such as `$`, `\`, `*`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_\(computing\)) and require escaping. In most common shells, the easiest way to escape the password is to surround it with single quotes (`'`). For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: -``` +{{< note >}} +Special characters such as `$`, `\`, `*`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. +In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). +For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: + +```shell kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb' ``` You do not need to escape special characters in passwords from files (`--from-file`). {{< /note >}} -Now make the pods: +Now make the Pods: ```shell -$ cat < pod.yaml +cat < pod.yaml apiVersion: v1 kind: List items: @@ -852,15 +959,16 @@ items: EOF ``` -Add the pods to the same kustomization.yaml +Add the pods to the same kustomization.yaml: + ```shell -$ cat <> kustomization.yaml +cat <> kustomization.yaml resources: - pod.yaml EOF ``` -Apply all those objects on the Apiserver by +Apply all those objects on the API server by running: ```shell kubectl apply -k . @@ -868,17 +976,20 @@ kubectl apply -k . Both containers will have the following files present on their filesystems with the values for each container's environment: -```shell +``` /etc/secret-volume/username /etc/secret-volume/password ``` -Note how the specs for the two pods differ only in one field; this facilitates -creating pods with different capabilities from a common pod config template. +Note how the specs for the two Pods differ only in one field; this facilitates +creating Pods with different capabilities from a common Pod template. -You could further simplify the base pod specification by using two Service Accounts: -one called, say, `prod-user` with the `prod-db-secret`, and one called, say, -`test-user` with the `test-db-secret`. Then, the pod spec can be shortened to, for example: +You could further simplify the base Pod specification by using two service accounts: + +1. `prod-user` with the `prod-db-secret` +1. `test-user` with the `test-db-secret` + +The Pod specification is shortened to: ```yaml apiVersion: v1 @@ -894,10 +1005,11 @@ spec: image: myClientImage ``` -### Use-case: Dotfiles in secret volume +### Use-case: dotfiles in a secret volume -In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply -make that key begin with a dot. For example, when the following secret is mounted into a volume: +You can make your data "hidden" by defining a key that begins with a dot. +This key represents a dotfile or "hidden" file. For example, when the following secret +is mounted into a volume, `secret-volume`: ```yaml apiVersion: v1 @@ -929,8 +1041,7 @@ spec: mountPath: "/etc/secret-volume" ``` - -The `secret-volume` will contain a single file, called `.secret-file`, and +The volume will contain a single file, called `.secret-file`, and the `dotfile-test-container` will have this file present at the path `/etc/secret-volume/.secret-file`. @@ -939,17 +1050,17 @@ Files beginning with dot characters are hidden from the output of `ls -l`; you must use `ls -la` to see them when listing directory contents. {{< /note >}} -### Use-case: Secret visible to one container in a pod +### Use-case: Secret visible to one container in a Pod Consider a program that needs to handle HTTP requests, do some complex business -logic, and then sign some messages with an HMAC. Because it has complex +logic, and then sign some messages with an HMAC. Because it has complex application logic, there might be an unnoticed remote file reading exploit in the server, which could expose the private key to an attacker. This could be divided into two processes in two containers: a frontend container which handles user interaction and business logic, but which cannot see the private key; and a signer container that can see the private key, and responds -to simple signing requests from the frontend (e.g. over localhost networking). +to simple signing requests from the frontend (for example, over localhost networking). With this partitioned approach, an attacker now has to trick the application server into doing something rather arbitrary, which may be harder than getting @@ -959,10 +1070,10 @@ it to read a file. ## Best practices -### Clients that use the secrets API +### Clients that use the Secret API -When deploying applications that interact with the secrets API, access should be -limited using [authorization policies]( +When deploying applications that interact with the Secret API, you should +limit access using [authorization policies]( /docs/reference/access-authn-authz/authorization/) such as [RBAC]( /docs/reference/access-authn-authz/rbac/). @@ -978,7 +1089,7 @@ the clients to inspect the values of all secrets that are in that namespace. The `watch` and `list` all secrets in a cluster should be reserved for only the most privileged, system-level components. -Applications that need to access the secrets API should perform `get` requests on +Applications that need to access the Secret API should perform `get` requests on the secrets they need. This lets administrators restrict access to all secrets while [white-listing access to individual instances]( /docs/reference/access-authn-authz/rbac/#referring-to-resources) that @@ -991,33 +1102,32 @@ https://github.com/kubernetes/community/blob/master/contributors/design-proposal to let clients `watch` individual resources has also been proposed, and will likely be available in future releases of Kubernetes. -## Security Properties - +## Security properties ### Protections -Because `secret` objects can be created independently of the `pods` that use +Because secrets can be created independently of the Pods that use them, there is less risk of the secret being exposed during the workflow of -creating, viewing, and editing pods. The system can also take additional -precautions with `secret` objects, such as avoiding writing them to disk where +creating, viewing, and editing Pods. The system can also take additional +precautions with Secrets, such as avoiding writing them to disk where possible. -A secret is only sent to a node if a pod on that node requires it. -Kubelet stores the secret into a `tmpfs` so that the secret is not written -to disk storage. Once the Pod that depends on the secret is deleted, kubelet +A secret is only sent to a node if a Pod on that node requires it. +The kubelet stores the secret into a `tmpfs` so that the secret is not written +to disk storage. Once the Pod that depends on the secret is deleted, the kubelet will delete its local copy of the secret data as well. -There may be secrets for several pods on the same node. However, only the -secrets that a pod requests are potentially visible within its containers. +There may be secrets for several Pods on the same node. However, only the +secrets that a Pod requests are potentially visible within its containers. Therefore, one Pod does not have access to the secrets of another Pod. -There may be several containers in a pod. However, each container in a pod has +There may be several containers in a Pod. However, each container in a Pod has to request the secret volume in its `volumeMounts` for it to be visible within -the container. This can be used to construct useful [security partitions at the +the container. This can be used to construct useful [security partitions at the Pod level](#use-case-secret-visible-to-one-container-in-a-pod). -On most Kubernetes-project-maintained distributions, communication between user -to the apiserver, and from apiserver to the kubelets, is protected by SSL/TLS. +On most Kubernetes distributions, communication between users +and the API server, and from the API server to the kubelets, is protected by SSL/TLS. Secrets are protected when transmitted over these channels. {{< feature-state for_k8s_version="v1.13" state="beta" >}} @@ -1027,11 +1137,11 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa ### Risks - - In the API server secret data is stored in {{< glossary_tooltip term_id="etcd" >}}; + - In the API server, secret data is stored in {{< glossary_tooltip term_id="etcd" >}}; therefore: - - Administrators should enable encryption at rest for cluster data (requires v1.13 or later) - - Administrators should limit access to etcd to admin users - - Administrators may want to wipe/shred disks used by etcd when no longer in use + - Administrators should enable encryption at rest for cluster data (requires v1.13 or later). + - Administrators should limit access to etcd to admin users. + - Administrators may want to wipe/shred disks used by etcd when no longer in use. - If running etcd in a cluster, administrators should make sure to use SSL/TLS for etcd peer-to-peer communication. - If you configure the secret through a manifest (JSON or YAML) file which has @@ -1040,15 +1150,10 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa encryption method and is considered the same as plain text. - Applications still need to protect the value of secret after reading it from the volume, such as not accidentally logging it or transmitting it to an untrusted party. - - A user who can create a pod that uses a secret can also see the value of that secret. Even - if apiserver policy does not allow that user to read the secret object, the user could - run a pod which exposes the secret. - - Currently, anyone with root on any node can read _any_ secret from the apiserver, - by impersonating the kubelet. It is a planned feature to only send secrets to + - A user who can create a Pod that uses a secret can also see the value of that secret. Even + if the API server policy does not allow that user to read the Secret, the user could + run a Pod which exposes the secret. + - Currently, anyone with root permission on any node can read _any_ secret from the API server, + by impersonating the kubelet. It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node. - - -{{% capture whatsnext %}} - -{{% /capture %}} diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md index 67a5574ac1..eac6267e79 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/configuration/taint-and-toleration.md @@ -73,6 +73,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the `Operator` defaults to `Equal` if not specified. {{< note >}} + There are two special cases: * An empty `key` with operator `Exists` matches all keys, values and effects which means this @@ -88,8 +89,9 @@ tolerations: ```yaml tolerations: - key: "key" - operator: "Exists" + operator: "Exists" ``` + {{< /note >}} The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`. diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 4e95d273ac..e22a742d36 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -124,9 +124,9 @@ Troubleshooting: - Verify all requirements above. - Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work? - Verify kubelet is running with `--cloud-provider=aws`. -- Check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like: - - `plugins.go:56] Registering credential provider: aws-ecr-key` - - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider` +- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like: + - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` + - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` ### Using Azure Container Registry (ACR) When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index 4177d203a4..00bd9fae34 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -120,7 +120,7 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/ Kubernetes built-in dockershim CRI does not support runtime handlers. -#### [containerd](https://containerd.io/) +#### {{< glossary_tooltip term_id="containerd" >}} Runtime handlers are configured through containerd's configuration at `/etc/containerd/config.toml`. Valid handlers are configured under the runtimes section: @@ -132,19 +132,20 @@ Runtime handlers are configured through containerd's configuration at See containerd's config documentation for more details: https://github.com/containerd/cri/blob/master/docs/config.md -#### [cri-o](https://cri-o.io/) +#### {{< glossary_tooltip term_id="cri-o" >}} -Runtime handlers are configured through cri-o's configuration at `/etc/crio/crio.conf`. Valid +Runtime handlers are configured through CRI-O's configuration at `/etc/crio/crio.conf`. Valid handlers are configured under the [crio.runtime -table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): +table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): ``` [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" ``` -See cri-o's config documentation for more details: -https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +See CRI-O's [config documentation][100] for more details. + +[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md ### Scheduling diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e9e7069fce..4d3da6ad11 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -44,7 +44,7 @@ The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. You can deploy and update a custom controller on a running cluster, independently -of the cluster's own lifecycle. Custom controllers can work with any kind of resource, +of the cluster's lifecycle. Custom controllers can work with any kind of resource, but they are especially effective when combined with custom resources. The [Operator pattern](https://coreos.com/blog/introducing-operators.html) combines custom resources and custom controllers. You can use custom controllers to encode domain knowledge @@ -61,7 +61,7 @@ When creating a new API, consider whether to [aggregate your API with the Kubern | You want to view your new types in a Kubernetes UI, such as dashboard, alongside built-in types. | Kubernetes UI support is not required. | | You are developing a new API. | You already have a program that serves your API and works well. | | You are willing to accept the format restriction that Kubernetes puts on REST resource paths, such as API Groups and Namespaces. (See the [API Overview](/docs/concepts/overview/kubernetes-api/).) | You need to have specific REST paths to be compatible with an already defined REST API. | -| Your resources are naturally scoped to a cluster or to namespaces of a cluster. | Cluster or namespace scoped resources are a poor fit; you need control over the specifics of resource paths. | +| Your resources are naturally scoped to a cluster or namespaces of a cluster. | Cluster or namespace scoped resources are a poor fit; you need control over the specifics of resource paths. | | You want to reuse [Kubernetes API support features](#common-features). | You don't need those features. | ### Declarative APIs @@ -83,7 +83,7 @@ Signs that your API might not be declarative include: - You talk about Remote Procedure Calls (RPCs). - Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects). - High bandwidth access (10s of requests per second sustained) needed. - - Store end-user data (such as images, PII, etc) or other large-scale data processed by applications. + - Store end-user data (such as images, PII, etc.) or other large-scale data processed by applications. - The natural operations on the objects are not CRUD-y. - The API is not easily modeled as objects. - You chose to represent pending operations with an operation ID or an operation object. @@ -96,7 +96,7 @@ Use a ConfigMap if any of the following apply: * You want to put the entire config file into one key of a configMap. * The main use of the config file is for a program running in a Pod on your cluster to consume the file to configure itself. * Consumers of the file prefer to consume via file in a Pod or environment variable in a pod, rather than the Kubernetes API. -* You want to perform rolling updates via Deployment, etc, when the file is updated. +* You want to perform rolling updates via Deployment, etc., when the file is updated. {{< note >}} Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure. @@ -140,7 +140,7 @@ and use a controller to handle events. ## API server aggregation -Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also handle custom resources in a generic way through [CRDs](#customresourcedefinitions). +Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also generically handle custom resources through [CRDs](#customresourcedefinitions). The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows you to provide specialized implementations for your custom resources by writing and deploying your own standalone API server. diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index 92b32796fe..b4a9579a36 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -305,7 +305,7 @@ PersistentVolumeClaim storage 1Gi 2Gi - - - {{< codenew file="admin/resource/pvc-limit-lower.yaml" >}} ```shell -kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo +kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-lower.yaml -n limitrange-demo ``` While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server: @@ -341,7 +341,7 @@ kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.y Describe the LimitRange with the following kubectl command: ```shell -$ kubectl describe limitrange/limit-memory-ratio-pod +kubectl describe limitrange/limit-memory-ratio-pod ``` ```shell diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index fcf7ff493a..45b48f62ae 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -22,7 +22,7 @@ updates. ## What is a Pod Security Policy? A _Pod Security Policy_ is a cluster-level resource that controls security -sensitive aspects of the pod specification. The `PodSecurityPolicy` objects +sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields. They allow an administrator to control the following: @@ -626,3 +626,9 @@ Refer to the [Sysctl documentation]( /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy). {{% /capture %}} + +{{% capture whatsnext %}} + +Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. + +{{% /capture %}} diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md index bcec8727f9..8c06308afc 100644 --- a/content/en/docs/concepts/security/overview.md +++ b/content/en/docs/concepts/security/overview.md @@ -142,7 +142,7 @@ Area of Concern for Code | Recommendation | --------------------------------------------- | ------------ | Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). | Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. | -3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to ensure that a regular scan of the code's dependencies are still secure with no CVE's currently filed against them. Each language has a tool for performing this check automatically. | +3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. | Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://www.owasp.org/index.php/Source_Code_Analysis_Tools | Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project | diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 3b660db019..0e34fa926f 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -31,7 +31,6 @@ Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) * IPv4 and IPv6 enabled Services (each Service must be for a single address family) - * Kubenet multi address family support (IPv4 and IPv6) * Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces ## Prerequisites @@ -40,7 +39,7 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack * Kubernetes 1.16 or later * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) - * Kubenet network plugin + * A network plugin that supports dual-stack (such as Kubenet or Calico) * Kube-proxy running in mode IPVS ## Enable IPv4/IPv6 dual-stack @@ -56,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidrs=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 5c085bcddc..989e319920 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -11,16 +11,16 @@ weight: 50 {{< toc >}} {{% capture overview %}} -A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. +A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints. -`NetworkPolicy` resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods. +NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods. {{% /capture %}} {{% capture body %}} ## Prerequisites -Network policies are implemented by the network plugin, so you must be using a networking solution which supports `NetworkPolicy` - simply creating the resource without a controller to implement it will have no effect. +Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. ## Isolated and Non-isolated Pods @@ -30,11 +30,11 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is Network policies do not conflict, they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result. -## The `NetworkPolicy` Resource +## The NetworkPolicy resource {#networkpolicy-resource} -See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) for a full definition of the resource. +See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource. -An example `NetworkPolicy` might look like this: +An example NetworkPolicy might look like this: ```yaml apiVersion: networking.k8s.io/v1 @@ -73,23 +73,25 @@ spec: port: 5978 ``` -*POSTing this to the API server will have no effect unless your chosen networking solution supports network policy.* +{{< note >}} +POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy. +{{< /note >}} -__Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy` +__Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), and [Object Management](/docs/concepts/overview/working-with-objects/object-management). -__spec__: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. +__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. -__podSelector__: Each `NetworkPolicy` includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. +__podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. -__policyTypes__: Each `NetworkPolicy` includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. +__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. -__ingress__: Each `NetworkPolicy` may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. +__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. -__egress__: Each `NetworkPolicy` may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. +__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. So, the example NetworkPolicy: @@ -107,7 +109,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network- There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section: -__podSelector__: This selects particular Pods in the same namespace as the `NetworkPolicy` which should be allowed as ingress sources or egress destinations. +__podSelector__: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations. __namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations. @@ -168,16 +170,7 @@ in that namespace. You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior. @@ -185,33 +178,13 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - ingress: - - {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} ### Default deny all egress traffic You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not change the default ingress isolation behavior. @@ -220,34 +193,13 @@ change the default ingress isolation behavior. If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - egress: - - {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} ### Default deny all ingress and all egress traffic You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic. @@ -255,9 +207,12 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Kubernetes supports SCTP as a `protocol` value in `NetworkPolicy` definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `“--feature-gates=SCTPSupport=true,...”`. When the feature gate is enabled, users can set the `protocol` field of a `NetworkPolicy` to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections. +To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,
`. +When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. -The CNI plugin has to support SCTP as `protocol` value in `NetworkPolicy`. +{{< note >}} +You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. +{{< /note >}} {{% /capture %}} @@ -266,6 +221,6 @@ The CNI plugin has to support SCTP as `protocol` value in `NetworkPolicy`. - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. -- See more [Recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. +- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. {{% /capture %}} diff --git a/content/en/docs/concepts/services-networking/service-topology.md b/content/en/docs/concepts/services-networking/service-topology.md index 223cf86c3e..7b3c58a84a 100644 --- a/content/en/docs/concepts/services-networking/service-topology.md +++ b/content/en/docs/concepts/services-networking/service-topology.md @@ -46,23 +46,6 @@ with it, while intrazonal traffic does not. Other common needs include being abl to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to Nodes connected to the same top-of-rack switch for the lowest latency. -## Prerequisites - -The following prerequisites are needed in order to enable topology aware service -routing: - - * Kubernetes 1.17 or later - * Kube-proxy running in iptables mode or IPVS mode - * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) - -## Enable Service Topology - -To enable service topology, enable the `ServiceTopology` feature gate for -kube-apiserver and kube-proxy: - -``` ---feature-gates="ServiceTopology=true" -``` ## Using Service Topology @@ -117,6 +100,98 @@ traffic as follows. it is used. +## Examples + +The following are common examples of using the Service Topology feature. + +### Only Node Local Endpoints + +A Service that only routes to node local endpoints. If no endpoints exist on the node, traffic is dropped: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" +``` + +### Prefer Node Local Endpoints + +A Service that prefers node local Endpoints but falls back to cluster wide endpoints if node local endpoints do not exist: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "*" +``` + + +### Only Zonal or Regional Endpoints + +A Service that prefers zonal then regional endpoints. If no endpoints exist in either, traffic is dropped. + + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" +``` + +### Prefer Node Local, Zonal, then Regional Endpoints + +A Service that prefers node local, zonal, then regional endpoints but falls back to cluster wide endpoints. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" + - "*" +``` + + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index f1a210d56b..c568b36231 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -225,7 +225,8 @@ There are a few reasons for using proxying for Services: In this mode, kube-proxy watches the Kubernetes master for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. Any connections to this "proxy port" -is proxied to one of the Service's backend Pods (as reported via +are +proxied to one of the Service's backend Pods (as reported via Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into account when deciding which backend Pod to use. @@ -276,9 +277,9 @@ state. When accessing a Service, IPVS directs traffic to one of the backend Pods. The IPVS proxy mode is based on netfilter hook function that is similar to -iptables mode, but uses hash table as the underlying data structure and works +iptables mode, but uses a hash table as the underlying data structure and works in the kernel space. -That means kube-proxy in IPVS mode redirects traffic with a lower latency than +That means kube-proxy in IPVS mode redirects traffic with lower latency than kube-proxy in iptables mode, with much better performance when synchronising proxy rules. Compared to the other proxy modes, IPVS mode also supports a higher throughput of network traffic. @@ -310,7 +311,7 @@ about Kubernetes or Services or Pods. If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based -on client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP" +on the client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP" (the default is "None"). You can also set the maximum session sticky time by setting `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately. @@ -421,7 +422,7 @@ Pods in other Namespaces must qualify the name as `my-service.my-ns`. These name will resolve to the cluster IP assigned for the Service. Kubernetes also supports DNS SRV (Service) records for named ports. If the -`"my-service.my-ns"` Service has a port named `"http"` with protocol set to +`"my-service.my-ns"` Service has a port named `"http"` with the protocol set to `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover the port number for `"http"`, as well as the IP address. @@ -506,7 +507,7 @@ For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` If you want a specific port number, you can specify a value in the `nodePort` field. The control plane will either allocate you that port or report that the API transaction failed. -This means that you need to take care about possible port collisions yourself. +This means that you need to take care of possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use. @@ -549,7 +550,7 @@ status: Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced. For LoadBalancer type of Services, when there is more than one port defined, all -ports must have the same protocol and the protocol must be one of `TCP`, `UDP` +ports must have the same protocol and the protocol must be one of `TCP`, `UDP`, and `SCTP`. Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created @@ -677,7 +678,7 @@ SSL, the ELB expects the Pod to authenticate itself over the encrypted connection, using a certificate. HTTP and HTTPS selects layer 7 proxying: the ELB terminates -the connection with the user, parse headers and inject the `X-Forwarded-For` +the connection with the user, parses headers, and injects the `X-Forwarded-For` header with the user's IP address (Pods only see the IP address of the ELB at the other end of its connection) when forwarding requests. @@ -849,7 +850,7 @@ traffic. Nodes without any Pods for a particular LoadBalancer Service will fail the NLB Target Group's health check on the auto-assigned `.spec.healthCheckNodePort` and not receive any traffic. -In order to achieve even traffic, either use a DaemonSet, or specify a +In order to achieve even traffic, either use a DaemonSet or specify a [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) to not locate on the same node. @@ -1182,7 +1183,7 @@ virtual IP address will simply transport the packets there. The Kubernetes project intends to improve support for L7 (HTTP) Services. The Kubernetes project intends to have more flexible ingress modes for Services -which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more. +that encompass the current ClusterIP, NodePort, and LoadBalancer modes and more. {{% /capture %}} diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index a0ec08063a..8346fc562c 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -115,7 +115,7 @@ Labels: type=local Annotations: Finalizers: [kubernetes.io/pv-protection] StorageClass: standard -Status: Available +Status: Terminating Claim: Reclaim Policy: Delete Access Modes: RWO diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 72118108a0..8627978427 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -19,8 +19,8 @@ collected. Deleting a DaemonSet will clean up the Pods it created. Some typical uses of a DaemonSet are: - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node. -- running a logs collection daemon on every node, such as `fluentd` or `logstash`. -- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/). +- running a logs collection daemon on every node, such as `fluentd` or `filebeat`. +- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond`, [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) or [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html). In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon. A more complex setup might use multiple DaemonSets for a single type of daemon, but with diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 59c77a4ae4..7077bd5ad3 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -136,7 +136,7 @@ metadata: name: frontend-9si5l namespace: default ownerReferences: - - apiVersion: extensions/v1beta1 + - apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: ReplicaSet @@ -261,7 +261,7 @@ the -d option. For example: ```shell kubectl proxy --port=8080 -curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ > -H "Content-Type: application/json" ``` @@ -273,7 +273,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol For example: ```shell kubectl proxy --port=8080 -curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ > -H "Content-Type: application/json" ``` diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index 3359616009..5547a977eb 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -The TTL controller provides a TTL mechanism to limit the lifetime of resource +The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource objects that have finished execution. TTL controller only handles [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for now, and may be expanded to handle other resources that will finish execution, diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index a55378ba3c..b54a8b6ca8 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -55,7 +55,7 @@ array has six possible fields: * The `message` field is a human-readable message indicating details about the transition. - + * The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition. * The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`". @@ -67,8 +67,6 @@ array has six possible fields: balancing pools of all matching Services; * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers) have started successfully; - * `Unschedulable`: the scheduler cannot schedule the Pod right now, for example - due to lack of resources or other constraints; * `ContainersReady`: all containers in the Pod are ready. @@ -185,18 +183,18 @@ Once Pod is assigned to a node by scheduler, kubelet starts creating containers Reason: ErrImagePull ... ``` - -* `Running`: Indicates that the container is executing without issues. Once a container enters into Running, `postStart` hook (if any) is executed. This state also displays the time when the container entered Running state. - + +* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state. + ```yaml ... State: Running Started: Wed, 30 Jan 2019 16:46:38 +0530 ... - ``` - + ``` + * `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed. - + ```yaml ... State: Terminated @@ -205,7 +203,7 @@ Once Pod is assigned to a node by scheduler, kubelet starts creating containers Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ... - ``` + ``` ## Pod readiness gate @@ -216,7 +214,7 @@ extra feedback or signals into `PodStatus`, Kubernetes 1.11 introduced a feature named [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). You can use the new field `ReadinessGate` in the `PodSpec` to specify additional conditions to be evaluated for Pod readiness. If Kubernetes cannot find such a -condition in the `status.conditions` field of a Pod, the status of the condition +condition in the `status.conditions` field of a Pod, the status of the condition is default to "`False`". Below is an example: ```yaml @@ -255,12 +253,6 @@ when both the following statements are true: To facilitate this change to Pod readiness evaluation, a new Pod condition `ContainersReady` is introduced to capture the old Pod `Ready` condition. -In K8s 1.11, as an alpha feature, the "Pod Ready++" feature has to be explicitly enabled by -setting the `PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -to true. - -In K8s 1.12, the feature is enabled by default. - ## Restart policy A PodSpec has a `restartPolicy` field with possible values Always, OnFailure, @@ -277,8 +269,8 @@ once bound to a node, a Pod will never be rebound to another node. ## Pod lifetime In general, Pods remain until a human or controller process explicitly removes them. -The control plane cleans up terminated Pods (with a phase of `Succeeded` or -`Failed`), when the number of Pods exceeds the configured threshold +The control plane cleans up terminated Pods (with a phase of `Succeeded` or +`Failed`), when the number of Pods exceeds the configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager). This avoids a resource leak as Pods are created and terminated over time. diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index 64abcae3f1..c58c72f28f 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -13,68 +13,50 @@ we're happy to have your help! Anyone can contribute, whether you're new to the project or you've been around a long time, and whether you self-identify as a developer, an end user, or someone who just can't stand seeing typos. -For information on the Kubernetes documentation - content and style, see the - [Documentation style overview](/docs/contribute/style/). +{{% /capture %}} {{% capture body %}} -## Types of docs contributors +## Getting Started -- A _member_ of the Kubernetes organization who has [signed the CLA](/docs/contribute/start#sign-the-cla) - and contributed some time and effort to the project. See - [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) - for specific criteria for membership. -- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has - expressed interest in reviewing documentation pull requests and who has been - added to the appropriate GitHub group and `OWNERS` files in the GitHub - repository, by a SIG Docs Approver. -- A SIG Docs _approver_ is a member in good standing who has shown a continued - commitment to the project. An approver can merge pull requests - and publish content on behalf of the Kubernetes organization. - Approvers can also represent SIG Docs in the larger Kubernetes community. - Some of the duties of a SIG Docs approver, such as coordinating a release, - require a significant time commitment. +Anyone can open an issue describing problems or desired improvements with documentation, or contribute a change with a pull request (PR). +Some tasks require more trust and need more access in the Kubernetes organization. +See [Participating in SIG Docs](/docs/contribute/participating/) for more details about +of roles and permissions. -## Ways to contribute to documentation +Kubernetes documentation resides in a GitHub repository. While we welcome +contributions from anyone, you do need basic comfort with git and GitHub to +operate effectively in the Kubernetes community. -This list is divided into things anyone can do, things Kubernetes organization -members can do, and things that require a higher level of access and familiarity -with SIG Docs processes. Contributing consistently over time can help you -understand some of the tooling and organizational decisions that have already -been made. +To get involved with documentation: -This is not an exhaustive list of ways you can contribute to the Kubernetes -documentation, but it should help you get started. +1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). +2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io). +3. Make sure you understand the basic processes for [improving content](https://kubernetes.io/docs/contribute/start/#improve-existing-content) and [reviewing changes](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests). -- [Anyone](/docs/contribute/start/) - - Open actionable issues -- [Member](/docs/contribute/start/) - - Improve existing docs - - Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - - Improve docs accessibility - - Provide non-binding feedback on PRs - - Write a blog post or case study -- [Reviewer](/docs/contribute/intermediate/) - - Document new features - - Triage and categorize issues - - Review PRs - - Create diagrams, graphics assets, and embeddable screencasts / videos - - Localization - - Contribute to other repos as a docs representative - - Edit user-facing strings in code - - Improve code comments, Godoc -- [Approver](/docs/contribute/advanced/) - - Publish contributor content by approving and merging PRs - - Participate in a Kubernetes release team as a docs representative - - Propose improvements to the style guide - - Propose improvements to docs tests - - Propose improvements to the Kubernetes website or other tooling +## Contributions best practices +- Do write clear and meaningful GIT commit messages. +- Make sure to include _Github Special Keywords_ which references the issue and automatically closes the issue when PR is merged. +- When you make a small change to a PR like fixing a typo, any style change, or changing grammar. Make sure you squash your commits so that you dont get a large number of commits for a relatively small change. +- Make sure you include a nice PR description depicting the code you have changes, why to change a following piece of code and ensuring there is sufficient information for the reviewer to understand your PR. +- Additional Readings : + - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) + - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) + - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) -## Additional ways to contribute +## Other ways to contribute - To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/). - To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started. {{% /capture %}} + +{{% capture whatsnext %}} + +- For more information about the basics of contributing to documentation, read [Start contributing](/docs/contribute/start/). +- Follow the [Kubernetes documentation style guide](/docs/contribute/style/style-guide/) when proposing changes. +- For more information about SIG Docs, read [Participating in SIG Docs](/docs/contribute/participating/). +- For more information about localizing Kubernetes docs, read [Localizing Kubernetes documentation](/docs/contribute/localization/). + +{{% /capture %}} diff --git a/content/en/docs/contribute/generate-ref-docs/_index.md b/content/en/docs/contribute/generate-ref-docs/_index.md index cf058d98ff..5720f0fe51 100644 --- a/content/en/docs/contribute/generate-ref-docs/_index.md +++ b/content/en/docs/contribute/generate-ref-docs/_index.md @@ -1,9 +1,12 @@ --- -title: Reference docs overview +title: Reference Docs Overview main_menu: true weight: 80 --- -Much of the Kubernetes reference documentation is generated from Kubernetes -source code, using scripts. The topics in this section document how to generate -this type of content. +The topics in this section document how to generate the Kubernetes +reference guides. + +To build the reference documentation, see the following guide: + +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md index ec96a56c39..6c4d93cd40 100644 --- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -1,13 +1,14 @@ --- title: Contributing to the Upstream Kubernetes Code content_template: templates/task +weight: 20 --- {{% capture overview %}} -This page shows how to contribute to the upstream kubernetes/kubernetes project -to fix bugs found in the Kubernetes API documentation or the `kube-*` -components such as `kube-apiserver`, `kube-controller-manager`, etc. +This page shows how to contribute to the upstream `kubernetes/kubernetes` project. +You can fix bugs found in the Kubernetes API documentation or the content of +the Kubernetes components such as `kubeadm`, `kube-apiserver`, and `kube-controller-manager`. If you instead want to regenerate the reference documentation for the Kubernetes API or the `kube-*` components from the upstream code, see the following instructions: @@ -17,28 +18,25 @@ API or the `kube-*` components from the upstream code, see the following instruc {{% /capture %}} - {{% capture prerequisites %}} -You need to have these tools installed: +- You need to have these tools installed: -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* [Golang](https://golang.org/doc/install) version 1.9.1 or later -* [Docker](https://docs.docker.com/engine/installation/) -* [etcd](https://github.com/coreos/etcd/) + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) version 1.13+ + - [Docker](https://docs.docker.com/engine/installation/) + - [etcd](https://github.com/coreos/etcd/) -Your $GOPATH environment variable must be set, and the location of `etcd` -must be in your $PATH environment variable. +- Your `GOPATH` environment variable must be set, and the location of `etcd` + must be in your `PATH` environment variable. -You need to know how to create a pull request to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). +- You need to know how to create a pull request to a GitHub repository. + Typically, this involves creating a fork of the repository. + For more information, see [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) + and [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). {{% /capture %}} - {{% capture steps %}} ## The big picture @@ -221,11 +219,10 @@ the same as the generated files in the master branch. The generated files in the contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain API elements that are not in 1.9, but are under development for 1.10. - ## Generating the published reference docs The preceding section showed how to edit a source file and then generate -several files, including `api/openapi-spec/swagger.json` in the +several files, including `api/openapi-spec/swagger.json` in the `kubernetes/kubernetes` repository. The `swagger.json` file is the OpenAPI definition file to use for generating the API reference documentation. @@ -238,8 +235,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube {{% capture whatsnext %}} * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) -* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) -* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) +* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) {{% /capture %}} - diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md index dafe7571c7..797a0f5371 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md @@ -1,12 +1,12 @@ --- title: Generating Reference Documentation for kubectl Commands content_template: templates/task +weight: 90 --- {{% capture overview %}} -This page shows how to automatically generate reference pages for the -commands provided by the `kubectl` tool. +This page shows how to generate the `kubectl` command reference. {{< note >}} This topic shows how to generate reference documentation for @@ -23,29 +23,12 @@ reference page, see {{% /capture %}} - {{% capture prerequisites %}} -* You need to have -[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -installed. - -* You need to have -[Golang](https://golang.org/doc/install) version 1.9.1 or later installed, -and your `$GOPATH` environment variable must be set. - -* You need to have -[Docker](https://docs.docker.com/engine/installation/) installed. - -* You need to know how to create a pull request to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). +{{< include "prerequisites-ref-docs.md" >}} {{% /capture %}} - {{% capture steps %}} ## Setting up the local repositories @@ -85,8 +68,7 @@ Remove the spf13 package from `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`. rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13 ``` -The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code. - +The kubernetes/kubernetes repository provides the `kubectl` and `kustomize` source code. * Determine the base directory of your clone of the [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository. @@ -108,15 +90,16 @@ The remaining steps refer to your base directory as ``. In your local k8s.io/kubernetes repository, check out the branch of interest, and make sure it is up to date. For example, if you want to generate docs for -Kubernetes 1.15, you could use these commands: +Kubernetes 1.17, you could use these commands: ```shell cd -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +git checkout v1.17.0 +git pull https://github.com/kubernetes/kubernetes v1.17.0 ``` -If you do not need to edit the kubectl source code, follow the instructions to [Edit the Makefile](#editing-makefile). +If you do not need to edit the `kubectl` source code, follow the instructions for +[Setting build variables](#setting-build-variables). ## Editing the kubectl source code @@ -152,65 +135,60 @@ milestone in your pull request. If you don’t have those permissions, you will need to work with someone who can set the label and milestone for you. {{< /note >}} -## Editing Makefile +## Setting build variables -Go to ``, and open the `Makefile` for editing: +Go to ``. On you command line, set the following environment variables. -* Set `K8SROOT` to ``. -* Set `WEBROOT` to ``. -* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example, -if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`. +* Set `K8S_ROOT` to ``. +* Set `WEB_ROOT` to ``. +* Set `K8S_RELEASE` to the version of the docs you want to build. + For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17. -For example, update the following variables: - -``` -WEBROOT=$(GOPATH)/src/github.com//website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 -``` - -## Creating a version directory - -The version directory is a staging area for the kubectl command reference build. -The YAML files in this directory are used to create the structure and navigation -of the kubectl command reference. - -In the `/gen-kubectldocs/generators` directory, if you do not already -have a directory named `v1_`, create one now by copying the directory -for the previous version. For example, suppose you want to generate docs for -Kubernetes 1.15, but you don't already have a `v1_15` directory. Then you could -create and populate a `v1_15` directory by running these commands: +For example: ```shell -mkdir gen-kubectldocs/generators/v1_15 -cp -r gen-kubectldocs/generators/v1_14/* gen-kubectldocs/generators/v1_15 +export WEB_ROOT=$(GOPATH)/src/github.com//website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 ``` -## Checking out a branch in k8s.io/kubernetes +## Creating a versioned directory -In your local repository, checkout the branch that has +The `createversiondirs` build target creates a versioned directory +and copies the kubectl reference configuration files to the versioned directory. +The versioned directory name follows the pattern of `v_`. + +In the `` directory, run the following build target: + +```shell +cd +make createversiondirs +``` + +## Checking out a release tag in k8s.io/kubernetes + +In your local `` repository, checkout the branch that has the version of Kubernetes that you want to document. For example, if you want -to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure +to generate docs for Kubernetes 1.17, checkout the `v1.17.0` tag. Make sure you local branch is up to date. ```shell cd -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +git checkout v1.17.0 +git pull https://github.com/kubernetes/kubernetes v1.17.0 ``` ## Running the doc generation code -In your local kubernetes-sigs/reference-docs repository, build and run the -kubectl command reference generation code. You might need to run the command as root: +In your local ``, run the `copycli` build target. The command runs as `root`: ```shell cd make copycli ``` -The `copycli` command will clean the staging directories, generate the kubectl command files, -and copy the collated kubectl reference HTML page and assets to ``. +The `copycli` command cleans the temporary build directory, generates the kubectl command files, +and copies the collated kubectl command reference HTML page and assets to ``. ## Locate the generated files @@ -237,7 +215,7 @@ static/docs/reference/generated/kubectl/kubectl-commands.html static/docs/reference/generated/kubectl/navData.js ``` -Additionally, the output might show the modified files: +The output may also include: ``` static/docs/reference/generated/kubectl/scroll.js @@ -275,13 +253,12 @@ A few minutes after your pull request is merged, your updated reference topics will be visible in the [published documentation](/docs/home). - {{% /capture %}} {{% capture whatsnext %}} -* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) -* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/) -* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/) +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) {{% /capture %}} diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md index 60f4d18ec0..35bf166d2b 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -1,14 +1,16 @@ --- title: Generating Reference Documentation for the Kubernetes API content_template: templates/task +weight: 50 --- {{% capture overview %}} -This page shows how to update the generated reference docs for the Kubernetes API. +This page shows how to update the Kubernetes API reference documentation. + The Kubernetes API reference documentation is built from the [Kubernetes OpenAPI spec](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json) -and tools from [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs). +using the [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) generation code. If you find bugs in the generated documentation, you need to [fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/). @@ -18,23 +20,12 @@ spec, continue reading this page. {{% /capture %}} - {{% capture prerequisites %}} -You need to have these tools installed: - -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* [Golang](https://golang.org/doc/install) version 1.9.1 or later - -You need to know how to create a pull request (PR) to a GitHub repository. -Typically, this involves creating a fork of the repository. For more -information, see -[Creating a Documentation Pull Request](/docs/contribute/start/) and -[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). +{{< include "prerequisites-ref-docs.md" >}} {{% /capture %}} - {{% capture steps %}} ## Setting up the local repositories @@ -83,49 +74,50 @@ The remaining steps refer to your base directory as ``. repository is `$GOPATH/src/github.com/kubernetes-sigs/reference-docs.` The remaining steps refer to your base directory as ``. - ## Generating the API reference docs This section shows how to generate the [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). -### Modifying the Makefile +### Setting build variables -Go to ``, and open the `Makefile` for editing: +* Set `K8S_ROOT` to ``. +* Set `WEB_ROOT` to ``. +* Set `K8S_RELEASE` to the version of the docs you want to build. + For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17. -* Set `K8SROOT` to ``. -* Set `WEBROOT` to ``. -* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example, -if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`. - -For example, update the following variables: - -``` -WEBROOT=$(GOPATH)/src/github.com//website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 -``` - -### Copying the OpenAPI spec - -Run the following command in ``: +For example: ```shell +export WEB_ROOT=$(GOPATH)/src/github.com//website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 +``` + +### Creating versioned directory and fetching Open API spec + +The `updateapispec` build target creates the versioned build directory. +After the directory is created, the Open API spec is fetched from the +`` repository. These steps ensure that the version +of the configuration files and Kubernetes Open API spec match the release version. +The versioned directory name follows the pattern of `v_`. + +In the `` directory, run the following build target: + +```shell +cd make updateapispec ``` -The output shows that the file was copied: - -```shell -cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json -``` - ### Building the API reference docs +The `copyapi` target builds the API reference and +copies the generated files to directories in ``. Run the following command in ``: ```shell -make api +cd +make copyapi ``` Verify that these two files have been generated: @@ -135,71 +127,57 @@ Verify that these two files have been generated: [ -e "/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` -### Creating directories for published docs - -Create the directories in `` for the generated API reference files: - -```shell -mkdir -p /static/docs/reference/generated/kubernetes-api/v1. -mkdir -p /static/docs/reference/generated/kubernetes-api/v1./css -mkdir -p /static/docs/reference/generated/kubernetes-api/v1./fonts -``` - -## Copying the generated docs to the kubernetes/website repository - -Run the following command in `` to copy the generated files to -your local kubernetes/website repository: - -```shell -make copyapi -``` - -Go to the base of your local kubernetes/website repository, and -see which files have been modified: +Go to the base of your local ``, and +view which files have been modified: ```shell cd git status ``` -The output shows the modified files: +The output is similar to: ``` -static/docs/reference/generated/kubernetes-api/v1.15/css/bootstrap.min.css -static/docs/reference/generated/kubernetes-api/v1.15/css/font-awesome.min.css -static/docs/reference/generated/kubernetes-api/v1.15/css/stylesheet.css -static/docs/reference/generated/kubernetes-api/v1.15/fonts/FontAwesome.otf -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.eot -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.svg -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.ttf -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff -static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff2 -static/docs/reference/generated/kubernetes-api/v1.15/index.html -static/docs/reference/generated/kubernetes-api/v1.15/jquery.scrollTo.min.js -static/docs/reference/generated/kubernetes-api/v1.15/navData.js -static/docs/reference/generated/kubernetes-api/v1.15/scroll.js +static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2 +static/docs/reference/generated/kubernetes-api/v1.17/index.html +static/docs/reference/generated/kubernetes-api/v1.17/js/jquery.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js +static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js ``` ## Updating the API reference index pages -* Open `/content/en/docs/reference/kubernetes-api/api-index.md` for editing, and update the API reference version number. For example: +When generating reference documentation for a new release, update the file, +`/content/en/docs/reference/kubernetes-api/api-index.md` with the new +version number. - ```markdown +* Open `/content/en/docs/reference/kubernetes-api/api-index.md` for editing, + and update the API reference version number. For example: + + ``` --- - title: v1.15 + title: v1.17 --- - [Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/) + [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/) ``` * Open `/content/en/docs/reference/_index.md` for editing, and add a - new link for the latest API reference. Remove the oldest API reference version. - There should be five links to the most recent API references. + new link for the latest API reference. Remove the oldest API reference version. + There should be five links to the most recent API references. ## Locally test the API reference Publish a local version of the API reference. -Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/). +Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.17/). ```shell cd @@ -220,8 +198,8 @@ to monitor your pull request until it has been merged. {{% capture whatsnext %}} -* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) -* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) -* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/) +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) {{% /capture %}} diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md index df0dfd56fa..f71db7afb1 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -1,228 +1,34 @@ --- title: Generating Reference Pages for Kubernetes Components and Tools content_template: templates/task +weight: 120 --- {{% capture overview %}} -This page shows how to use the `update-imported-docs` tool to generate -reference documentation for tools and components in the -[Kubernetes](https://github.com/kubernetes/kubernetes) repository. +This page shows how to build the Kubernetes component and tool reference pages. {{% /capture %}} {{% capture prerequisites %}} -* You need a machine that is running Linux or macOS. - -* Install the following: - - * [Python](https://www.python.org/downloads/) v3.7.x - * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - * [Golang](https://golang.org/doc/install) version 1.13+ - * [Pip](https://pypi.org/project/pip/) used to install PyYAML - * [PyYAML](https://pyyaml.org/) v5.1.2 - * [make](https://www.gnu.org/software/make/) - * [gcc compiler/linker](https://gcc.gnu.org/) - -* The `Go` binary must be in your path. The `update-imported-docs` tool sets your GOPATH. - -* You need to know how to create a pull request to a GitHub repository. -This involves creating your own fork of the repository. For more -information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone). +Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) +in the Reference Documentation Quickstart guide. {{% /capture %}} {{% capture steps %}} -## Getting the repository - -Make sure your `website` fork is up-to-date with the `kubernetes/website` master and then clone your `website` fork. - -```shell -mkdir github.com -cd github.com -git clone git@github.com:/website.git -``` - -Determine the base directory of your clone. For example, if you followed the -preceding step to get the repository, your base directory is -`github.com/website.` The remaining steps refer to your base directory as -``. - -The `update-imported-docs` tool generates the reference documentation for the -Kubernetes components from the Kubernetes source code. The tool automatically -clones the `kubernetes/kubernetes` repository. If you want to change the -reference documentation, please follow [this -guide](/docs/contribute/generate-ref-docs/contribute-upstream). - -## Overview of update-imported-docs - -The `update-imported-docs` tool is located in the `kubernetes/website/update-imported-docs/` -directory. The tool consists of a Python script that reads a YAML configuration file and performs the following steps: - -1. Clones the related repositories specified in a configuration file. For the - purpose of generating reference docs, the repository that is cloned by - default is `kubernetes-sigs/reference-docs`. -1. Runs commands under the cloned repositories to prepare the docs generator and - then generates the Markdown files. -1. Copies the generated Markdown files to a local clone of the `kubernetes/website` - repository under locations specified in the configuration file. -1. Updates `kubectl` command links from `kubectl`.md to the `kubectl` command reference. - -When the Markdown files are in your local clone of the `kubernetes/website` -repository, you can submit them in a [pull request](/docs/contribute/start/) -to `kubernetes/website`. - -## Configuration file format - -Each config file may contain multiple repos that will be imported together. When -necessary, you can customize the configuration file by manually editing it. You -may create new config files for importing other groups of documents. Imported -documents must follow these guidelines: - -1. Adhere to the [Documentation Style Guide](/docs/contribute/style/style-guide/). - -1. Have `title` defined in the front matter. For example: - - ``` - --- - title: Title Displayed in Table of Contents - --- - - Rest of the .md file... - ``` -1. Be listed in the `kubernetes/website/data/reference.yml` file - -The following is an example of the YAML configuration file: - -```yaml -repos: -- name: community - remote: https://github.com/kubernetes/community.git - branch: master - files: - - src: contributors/devel/README.md - dst: docs/imported/community/devel.md - - src: contributors/guide/README.md - dst: docs/imported/community/guide.md -``` - -Note: `generate-command` is an optional entry, which can be used to run a -given command or a short script to generate the docs from within a repo. - -## Customizing the reference.yml config file - -Open `/update-imported-docs/reference.yml` for editing. -Do not change the content for the `generate-command` entry unless you understand -what it is doing and need to change the specified release branch. - -```yaml -repos: -- name: reference-docs - remote: https://github.com/kubernetes-sigs/reference-docs.git - # This and the generate-command below needs a change when reference-docs has - # branches properly defined - branch: master - generate-command: | - cd $GOPATH - git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes - cd src/k8s.io/kubernetes - git checkout release-1.17 - make generated_files - cp -L -R vendor $GOPATH/src - rm -r vendor - cd $GOPATH - go get -v github.com/kubernetes-sigs/reference-docs/gen-compdocs - cd src/github.com/kubernetes-sigs/reference-docs/ - make comp -``` - -In reference.yml, the `files` field is a list of `src` and `dst` fields. The `src` field -specifies the location of a generated Markdown file, and the `dst` field specifies -where to copy this file in the cloned `kubernetes/website` repository. -For example: - -```yaml -repos: -- name: reference-docs - remote: https://github.com/kubernetes-sigs/reference-docs.git - files: - - src: gen-compdocs/build/kube-apiserver.md - dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md - ... -``` - -Note that when there are many files to be copied from the same source directory -to the same destination directory, you can use wildcards in the value given to -`src` and you can just provide the directory name as the value for `dst`. -For example: - -```yaml - files: - - src: gen-compdocs/build/kubeadm*.md - dst: content/en/docs/reference/setup-tools/kubeadm/generated/ -``` - -## Running the update-imported-docs tool - -After having reviewed and/or customized the `reference.yaml` file, you can run -the `update-imported-docs` tool: - -```shell -cd /update-imported-docs -./update-imported-docs reference.yml -``` - -## Fixing Links - -To fix relative links within your imported files, set the repo config's -`gen-absolute-links` property to `true`. You can find an example of this in -[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml). - -## Adding and committing changes in kubernetes/website - -List the files that were generated and copied to the `kubernetes/website` -repository: - -``` -cd -git status -``` - -The output shows the new and modified files. For example, the output -might look like this: - -```shell -... - - modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md - modified: content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/kube-proxy.md - modified: content/en/docs/reference/command-line-tools-reference/kube-scheduler.md - modified: content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md - modified: content/en/docs/reference/kubectl/kubectl.md -... -``` - -Run `git add` and `git commit` to commit the files. - -## Creating a pull request - -Create a pull request to the `kubernetes/website` repository. Monitor your -pull request, and respond to review comments as needed. Continue to monitor -your pull request until it is merged. - -A few minutes after your pull request is merged, your updated reference -topics will be visible in the -[published documentation](/docs/home/). +Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) +to generate the Kubernetes component and tool reference pages. {{% /capture %}} {{% capture whatsnext %}} +* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) + {{% /capture %}} diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md new file mode 100644 index 0000000000..a777fb77e5 --- /dev/null +++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -0,0 +1,21 @@ + +### Requirements: + +- You need a machine that is running Linux or macOS. + +- You need to have these tools installed: + + - [Python](https://www.python.org/downloads/) v3.7.x + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) version 1.13+ + - [Pip](https://pypi.org/project/pip/) used to install PyYAML + - [PyYAML](https://pyyaml.org/) v5.1.2 + - [make](https://www.gnu.org/software/make/) + - [gcc compiler/linker](https://gcc.gnu.org/) + - [Docker](https://docs.docker.com/engine/installation/) (Required only for `kubectl` command reference) + +- Your `PATH` environment variable must include the required build tools, such as the `Go` binary and `python`. + +- You need to know how to create a pull request to a GitHub repository. + This involves creating your own fork of the repository. For more + information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone). diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md new file mode 100644 index 0000000000..095bc05c21 --- /dev/null +++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md @@ -0,0 +1,260 @@ +--- +title: Quickstart +content_template: templates/task +weight: 40 +--- + +{{% capture overview %}} + +This page shows how to use the `update-imported-docs` script to generate +the Kubernetes reference documentation. The script automates +the build setup and generates the reference documentation for a release. + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "prerequisites-ref-docs.md" >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Getting the docs repository + +Make sure your `website` fork is up-to-date with the `kubernetes/website` master and clone +your `website` fork. + +```shell +mkdir github.com +cd github.com +git clone git@github.com:/website.git +``` + +Determine the base directory of your clone. For example, if you followed the +preceding step to get the repository, your base directory is +`github.com/website.` The remaining steps refer to your base directory as +``. + +{{< note>}} +If you want to change the content of the component tools and API reference, +see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contribute-upstream). +{{< /note >}} + +## Overview of update-imported-docs + +The `update-imported-docs` script is located in the `/update-imported-docs/` +directory. + +The script builds the following references: + +* Component and tool reference pages +* The `kubectl` command reference +* The Kubernetes API reference + +The `update-imported-docs` script generates the Kubernetes reference documentation +from the Kubernetes source code. The script creates a temporary directory +under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and +`kubernetes-sigs/reference-docs` into this directory. +The script sets your `GOPATH` to this temporary directory. +Three additional environment variables are set: + +* `K8S_RELEASE` +* `K8S_ROOT` +* `K8S_WEBROOT` + +The script requires two arguments to run successfully: + +* A YAML configuration file (`reference.yml`) +* A release version, for example:`1.17` + +The configuration file contains a `generate-command` field. +The `generate-command` field defines a series of build instructions +from `kubernetes-sigs/reference-docs/Makefile`. The `K8S_RELEASE` variable +determines the version of the release. + +The `update-imported-docs` script performs the following steps: + +1. Clones the related repositories specified in a configuration file. For the + purpose of generating reference docs, the repository that is cloned by + default is `kubernetes-sigs/reference-docs`. +1. Runs commands under the cloned repositories to prepare the docs generator and + then generates the HTML and Markdown files. +1. Copies the generated HTML and Markdown files to a local clone of the `` + repository under locations specified in the configuration file. +1. Updates `kubectl` command links from `kubectl`.md to the refer to + the sections in the `kubectl` command reference. + +When the generated files are in your local clone of the `` +repository, you can submit them in a [pull request](/docs/contribute/start/) +to ``. + +## Configuration file format + +Each configuration file may contain multiple repos that will be imported together. When +necessary, you can customize the configuration file by manually editing it. You +may create new config files for importing other groups of documents. +The following is an example of the YAML configuration file: + +```yaml +repos: +- name: community + remote: https://github.com/kubernetes/community.git + branch: master + files: + - src: contributors/devel/README.md + dst: docs/imported/community/devel.md + - src: contributors/guide/README.md + dst: docs/imported/community/guide.md +``` + +Single page Markdown documents, imported by the tool, must adhere to +the [Documentation Style Guide](/docs/contribute/style/style-guide/). + +## Customizing reference.yml + +Open `/update-imported-docs/reference.yml` for editing. +Do not change the content for the `generate-command` field unless you understand +how the command is used to build the references. +You should not need to update `reference.yml`. At times, changes in the +upstream source code, may require changes to the configuration file +(for example: golang version dependencies and third-party library changes). +If you encounter build issues, contact the SIG-Docs team on the +[#sig-docs Kubernetes Slack channel](https://kubernetes.slack.com). + +{{< note >}} +The `generate-command` is an optional entry, which can be used to run a +given command or a short script to generate the docs from within a repository. +{{< /note >}} + +In `reference.yml`, `files` contains a list of `src` and `dst` fields. +The `src` field contains the location of a generated Markdown file in the cloned +`kubernetes-sigs/reference-docs` build directory, and the `dst` field specifies +where to copy this file in the cloned `kubernetes/website` repository. +For example: + +```yaml +repos: +- name: reference-docs + remote: https://github.com/kubernetes-sigs/reference-docs.git + files: + - src: gen-compdocs/build/kube-apiserver.md + dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md + ... +``` + +Note that when there are many files to be copied from the same source directory +to the same destination directory, you can use wildcards in the value given to +`src`. You must provide the directory name as the value for `dst`. +For example: + +```yaml + files: + - src: gen-compdocs/build/kubeadm*.md + dst: content/en/docs/reference/setup-tools/kubeadm/generated/ +``` + +## Running the update-imported-docs tool + +You can run the `update-imported-docs` tool as follows: + +```shell +cd /update-imported-docs +./update-imported-docs +``` + +For example: + +```shell +./update-imported-docs reference.yml 1.17 +``` + + +## Fixing Links + +The `release.yml` configuration file contains instructions to fix relative links. +To fix relative links within your imported files, set the`gen-absolute-links` +property to `true`. You can find an example of this in +[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml). + +## Adding and committing changes in kubernetes/website + +List the files that were generated and copied to ``: + +```shell +cd +git status +``` + +The output shows the new and modified files. The generated output varies +depending upon changes made to the upstream source code. + +### Generated component tool files + +``` +content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-proxy.md +content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md +content/en/docs/reference/kubectl/kubectl.md +``` + +### Generated kubectl command reference files + +``` +static/docs/reference/generated/kubectl/kubectl-commands.html +static/docs/reference/generated/kubectl/navData.js +static/docs/reference/generated/kubectl/scroll.js +static/docs/reference/generated/kubectl/stylesheet.css +static/docs/reference/generated/kubectl/tabvisibility.js +static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css +static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css +static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js +static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js +static/docs/reference/generated/kubectl/css/font-awesome.min.css +``` + +### Generated Kubernetes API reference directories and files + +``` +static/docs/reference/generated/kubernetes-api/v1.17/index.html +static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js +static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js +static/docs/reference/generated/kubernetes-api/v1.17/js/query.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2 +``` + +Run `git add` and `git commit` to commit the files. + +## Creating a pull request + +Create a pull request to the `kubernetes/website` repository. Monitor your +pull request, and respond to review comments as needed. Continue to monitor +your pull request until it is merged. + +A few minutes after your pull request is merged, your updated reference +topics will be visible in the +[published documentation](/docs/home/). + +{{% /capture %}} + +{{% capture whatsnext %}} + +To generate the individual reference documentation by manually setting up the required build repositories and +running the build targets, see the following guides: + +* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) +* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) + +{{% /capture %}} diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 8982e29d99..2522a832f3 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -54,16 +54,16 @@ Once you've opened a localization PR, you can become members of the Kubernetes G ### Add your localization team in GitHub -Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). +Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). -Members of `sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. +Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. -The `sig-docs-**-reviews` team automates review assignment for new PRs. +For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. -Members of `sig-docs-l10n-admins` can create new development branches to coordinate translation efforts. +Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts. + +Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. -Members of `website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. - ### Configure the workflow Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label lets you filter issues and pull requests for your specific language. @@ -240,9 +240,9 @@ Because localization projects are highly collaborative efforts, we encourage tea To collaborate on a development branch: -1. A team member of [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) opens a development branch from a source branch on https://github.com/kubernetes/website. +1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website. - Your team approvers joined the `sig-docs-l10n-admins` team when you [added your localization team](#add-your-localization-team-in-github) to the `kubernetes/org` repository. + Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. We recommend the following branch naming scheme: diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md index c9785388ab..b63c33e915 100644 --- a/content/en/docs/contribute/participating.md +++ b/content/en/docs/contribute/participating.md @@ -19,7 +19,7 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to file issues about content or comment on pull requests in progress. -Within SIG Docs, you may also become a [member](#members), +You can also become a [member](#members), [reviewer](#reviewers), or [approver](#approvers). These roles require greater access and entail certain responsibilities for approving and committing changes. See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) @@ -34,51 +34,47 @@ aspects of Kubernetes -- the Kubernetes website and documentation. ## Roles and responsibilities -When a pull request is merged to the branch used to publish content (currently -`master`), that content is published and available to the world. To ensure that -the quality of our published content is high, we limit merging pull requests to -SIG Docs approvers. Here's how it works. +- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/start#sign-the-cla) and have a GitHub account. +- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria. +- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has + expressed interest in reviewing documentation pull requests, and has been + added to the appropriate GitHub group and `OWNERS` files in the GitHub + repository by a SIG Docs Approver. +- A SIG Docs **Approver** is a member in good standing who has shown a continued + commitment to the project. An approver can merge pull requests + and publish content on behalf of the Kubernetes organization. + Approvers can also represent SIG Docs in the larger Kubernetes community. + Some duties of a SIG Docs approver, such as coordinating a release, + require a significant time commitment. -- When a pull request has both the `lgtm` and `approve` labels and has no `hold` - labels, the pull request merges automatically. -- Kubernetes organization members and SIG Docs approvers can add comments to - prevent automatic merging of a given pull request (by adding a `/hold` comment - or withholding a `/lgtm` comment). -- Any Kubernetes member can add the `lgtm` label, by adding a `/lgtm` comment. -- Only an approver who is a member of SIG Docs can cause a pull request to merge - by adding an `/approve` comment. Some approvers also perform additional - specific roles, such as [PR Wrangler](#pr-wrangler) or - [SIG Docs chairperson](#sig-docs-chairperson). +## Anyone -For more information about expectations and differences between the roles of -Kubernetes organization member and SIG Docs approvers, see -[Types of contributor](/docs/contribute#types-of-contributor). The following -sections cover more details about these roles and how they work within -SIG Docs. +Anyone can do the following: -### Anyone +- Open a GitHub issue against any part of Kubernetes, including documentation. +- Provide non-binding feedback on a pull request/ +- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging. + {{< note >}} + If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems. + {{< /note >}} -Anyone can file an issue against any part of Kubernetes, including documentation. +After [signing the CLA](/docs/contribute/start#sign-the-cla), anyone can also: +- Open a pull request to improve existing content, add new content, or write a blog post or case study. -Anyone who has signed the CLA can submit a pull request. If you cannot sign the -CLA, the Kubernetes project cannot accept your contribution. +## Members -### Members +Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community, +and frequently requests reviews from members of other SIGs for technical accuracy. -Any member of the [Kubernetes organization](https://github.com/kubernetes) can -review a pull request, and SIG Docs team members frequently request reviews from -members of other SIGs for technical accuracy. -SIG Docs also welcomes reviews and feedback regardless of a person's membership -status in the Kubernetes organization. You can indicate your approval by adding -a comment of `/lgtm` to a pull request. If you are not a member of the -Kubernetes organization, your `/lgtm` has no effect on automated systems. +Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following: -Any member of the Kubernetes organization can add a `/hold` comment to prevent -the pull request from being merged. Any member can also remove a `/hold` comment -to cause a PR to be merged if it already has both `/lgtm` and `/approve` applied -by appropriate people. +- Everything listed under [Anyone](#anyone) +- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request. +- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels. +- Use the `/assign` comment to assign a reviewer to a pull request. -#### Becoming a member +### Becoming a member After you have successfully submitted at least 5 substantive pull requests, you can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member) @@ -86,11 +82,11 @@ in the Kubernetes organization. Follow these steps: 1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership. - - Ask for sponsorship in the [#sig-docs channel on the + + Ask for sponsorship in the [#sig-docs channel on the Kubernetes Slack instance](https://kubernetes.slack.com) or on the [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - + {{< note >}} Don't send a direct email or Slack direct message to an individual SIG Docs member. @@ -108,20 +104,29 @@ in the Kubernetes organization. Follow these steps: GitHub issue to show approval and then closes the GitHub issue. Congratulations, you are now a member! -If for some reason your membership request is not accepted right away, the +If your membership request is not accepted, the membership committee provides information or steps to take before applying again. -### Reviewers +## Reviewers Reviewers are members of the [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs). +GitHub group. Reviewers review documentation pull requests and provide feedback on proposed +changes. Reviewers can: -Reviewers review documentation pull requests and provide feedback on proposed -changes. +- Do everything listed under [Anyone](#anyone) and [Members](#members) +- Document new features +- Triage and categorize issues +- Review pull requests and provide binding feedback +- Create diagrams, graphics assets, and embeddable screencasts and videos +- Localization +- Edit user-facing strings in code +- Improve code comments -Automation assigns reviewers to pull requests, and contributors can request a +### Assigning reviewers to pull requests + +Automation assigns reviewers to all pull requests. You can request a review from a specific reviewer with a comment on the pull request: `/assign [@_github_handle]`. To indicate that a pull request is technically accurate and requires no further changes, a reviewer adds a `/lgtm` comment to the pull @@ -129,18 +134,14 @@ request. If the assigned reviewer has not yet reviewed the content, another reviewer can step in. In addition, you can assign technical reviewers and wait for them to -provide `/lgtm`. +provide a `/lgtm` comment. -For a trivial change or one that needs no technical review, the SIG Docs -[approver](#approvers) can provide the `/lgtm` as well. +For a trivial change or one that needs no technical review, SIG Docs +[approvers](#approvers) can provide the `/lgtm` as well. -A `/approve` comment from a reviewer is ignored by automation. +An `/approve` comment from a reviewer is ignored by automation. -For more about how to become a SIG Docs reviewer and the responsibilities and -time commitment involved, see -[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer). - -#### Becoming a reviewer +### Becoming a reviewer When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), @@ -161,26 +162,27 @@ If you are approved, request that a current SIG Docs approver add you to the GitHub group. Only members of the `kubernetes-website-admins` GitHub group can add new members to a GitHub group. -### Approvers +## Approvers Approvers are members of the [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs). -Approvers have the ability to merge a PR, and thus, to publish content on the -Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on -the PR. If someone who is not an approver leaves the approval comment, -automation ignores it. +Approvers can do the following: + +- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) +- Publish contributor content by approving and merging pull requests using the `/approve` comment. + If someone who is not an approver leaves the approval comment, automation ignores it. +- Participate in a Kubernetes release team as a docs representative +- Propose improvements to the style guide +- Propose improvements to docs tests +- Propose improvements to the Kubernetes website or other tooling If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review. -For more about how to become a SIG Docs approver and the responsibilities and -time commitment involved, see -[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer). - -#### Becoming an approver +### Becoming an approver When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), @@ -201,34 +203,29 @@ If you are approved, request that a current SIG Docs approver add you to the GitHub group. Only members of the `kubernetes-website-admins` GitHub group can add new members to a GitHub group. -#### Approver responsibilities +### Approver responsibilities Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities: - Approvers can use the `/approve` command, which merges PRs into the repo. A careless merge can break the site, so be sure that when you merge something, you mean it. - -- Make sure that proposed changes meet the contribution guidelines. + +- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). If you ever have a question, or you're not sure about something, feel free to call for additional review. -- Verify that netlify tests pass before you `/approve` a PR. +- Verify that Netlify tests pass before you `/approve` a PR. Netlify tests must pass before approving -- Visit the netlify page preview for a PR to make sure things look good before approving. +- Visit the Netlify page preview for a PR to make sure things look good before approving. -#### PR Wrangler - -SIG Docs approvers participate in the -[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) -for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See -[Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) +- Participate in the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this +rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) for more details. -#### SIG Docs chairperson +## SIG Docs chairperson Each SIG, including SIG Docs, selects one or more SIG members to act as chairpersons. These are points of contact between SIG Docs and other parts of @@ -285,6 +282,24 @@ The combination of OWNERS files and front-matter in Markdown files determines the advice PR owners get from automated systems about who to ask for technical and editorial review of their PR. +## How merging works + +When a pull request is merged to the branch used to publish content (currently +`master`), that content is published and available to the world. To ensure that +the quality of our published content is high, we limit merging pull requests to +SIG Docs approvers. Here's how it works. + +- When a pull request has both the `lgtm` and `approve` labels, has no `hold` + labels, and all tests are passing, the pull request merges automatically. +- Kubernetes organization members and SIG Docs approvers can add comments to + prevent automatic merging of a given pull request (by adding a `/hold` comment + or withholding a `/lgtm` comment). +- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. +- Only SIG Docs approvers can merge a pull request + by adding an `/approve` comment. Some approvers also perform additional + specific roles, such as [PR Wrangler](#pr-wrangler) or + [SIG Docs chairperson](#sig-docs-chairperson). + {{% /capture %}} {{% capture whatsnext %}} @@ -295,5 +310,3 @@ For more information about contributing to the Kubernetes documentation, see: - [Documentation style](/docs/contribute/style/) {{% /capture %}} - - diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md index ff1f62b149..4af5f6d5ce 100644 --- a/content/en/docs/contribute/start.md +++ b/content/en/docs/contribute/start.md @@ -196,15 +196,38 @@ to base your work on. Use these guidelines to make the decision: - Use `master` for fixing problems in content that is already published, or making improvements to content that already exists. - - Use a release branch (such as `dev-{{< release-branch >}}` for the {{< release-branch >}} release) to document upcoming features - or changes for an upcoming release that is not yet published. -- Use a feature branch that has been agreed upon by SIG Docs to collaborate on - big improvements or changes to the existing documentation, including content - reorganization or changes to the look and feel of the website. +- Use `master` to document something that is already part of the current + Kubernetes release, but isn't yet documented. You should write this content + in English first, and then localization teams will pick that change up as a + localization task. +- If you're working on a localization, you should follow the convention for + that particular localization. To find this out, you can look at other + pull requests (tip: search for `is:pr is:merged label:language/xx`) + {{< comment >}}Localization note: when localizing that tip, replace `xx` + with the actual ISO3166 two-letter code for your target locale.{{< /comment >}} + - Some localization teams work with PRs that target `master` + - Some localization teams work with a series of long-lived branches, and + periodically merge these to `master`. This kind of branch has a name like + dev-\-\.\; for example: + `dev-{{< release-branch >}}-ja.1`. +- If you're writing or updating documentation for a feature change release, + then you need to know the major and minor version of Kubernetes that + the change will first appear in. + - For example, if the feature gate JustAnExample is going to move from alpha + to beta in the next minor version, you need to know what the next minor + version number is. + - Find the release branch named for that version. For example, features that + changed in the v{{< release-branch >}} release got documented in the branch + named `dev-{{< release-branch >}}`. If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or attend a weekly SIG Docs meeting to get clarity. +{{< note >}} +If you already submitted your pull request and you know that the Base Branch +was wrong, you (and only you, the submitter) can change it. +{{< /note >}} + ### Submit a pull request Follow these steps to submit a pull request to improve the Kubernetes diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md index 6c315ef0ad..5d3f5790c7 100644 --- a/content/en/docs/contribute/style/content-guide.md +++ b/content/en/docs/contribute/style/content-guide.md @@ -47,7 +47,7 @@ Before adding content, ask yourself this: - Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations? - If yes, then: - Does the project have its own documentation? - - if yes, link to the project's documention from the Kubernetes documentation + - if yes, link to the project's documentation from the Kubernetes documentation - if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation - If no, then: - Stop! @@ -64,7 +64,7 @@ Below are general categories of non-Kubernetes project content along with guidel - Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations - Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation - Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content - - Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions + - Example: including [kubeadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions - Not Allowed: - Adding content that duplicates documentation in another repository - Examples: diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 22e55e3da8..50e49734a3 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -115,8 +115,9 @@ When adding a new standalone sample file, such as a YAML file, place the code in one of the `/examples/` subdirectories where `` is the language for the topic. In your topic file, use the `codenew` shortcode: -
{{< codenew file="<RELPATH>/my-example-yaml>" >}}
- +```none +{{/my-example-yaml>" */>}} +``` where `` is the path to the file to include, relative to the `examples` directory. The following Hugo shortcode references a YAML file located at `/content/en/examples/pods/storage/gce-volume.yaml`. diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index bdd6b78d24..7efffa4ef6 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -19,12 +19,7 @@ This section of the Kubernetes documentation contains references. ## API Reference * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes. -* Kubernetes API Versions - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) +* [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## API Client Libraries @@ -39,18 +34,17 @@ client libraries: ## CLI Reference -* [kubectl](/docs/user-guide/kubectl-overview) - Main CLI tool for running commands and managing Kubernetes clusters. - * [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl. -* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster. -* [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters. +* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl. +* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster. ## Config Reference -* [kubelet](/docs/admin/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy. -* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers. -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes. -* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends. -* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler that manages availability, performance, and capacity. +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity. ## Design Docs diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 469d1267f0..3500ed0c53 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -969,9 +969,10 @@ Specifying `Equivalent` is recommended, and ensures that webhooks continue to in resources they expect when upgrades enable new versions of the resource in the API server. When a resource stops being served by the API server, it is no longer considered equivalent to other versions of that resource that are still served. -For example, deprecated `extensions/v1beta1` deployments are scheduled to stop being served by default in v1.16. -Once that occurs, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule -would no longer intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering +For example, `extensions/v1beta1` deployments were first deprecated and then removed (in Kubernetes v1.16). + +Since that removal, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule +does not intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering for stable versions of resources. This example shows a validating webhook that intercepts modifications to deployments (no matter the API group or version), diff --git a/content/en/docs/reference/glossary/container-runtime.md b/content/en/docs/reference/glossary/container-runtime.md index 38a11e1964..c45bed0f7b 100644 --- a/content/en/docs/reference/glossary/container-runtime.md +++ b/content/en/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -Kubernetes supports several container runtimes: [Docker](http://www.docker.com), -[containerd](https://containerd.io), [cri-o](https://cri-o.io/), -[rktlet](https://github.com/kubernetes-incubator/rktlet) and any implementation of -the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). +Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}}, +{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, +and any implementation of the [Kubernetes CRI (Container Runtime +Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/en/docs/reference/glossary/device-plugin.md b/content/en/docs/reference/glossary/device-plugin.md index d29b495953..d1fb91cce4 100644 --- a/content/en/docs/reference/glossary/device-plugin.md +++ b/content/en/docs/reference/glossary/device-plugin.md @@ -4,14 +4,26 @@ id: device-plugin date: 2019-02-02 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - Containers running in Kubernetes that provide access to a vendor specific resource. + Software extensions to let Pods access devices that need vendor-specific initialization or setup aka: tags: - fundamental - extension --- - Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource. + Device plugins run on worker +{{< glossary_tooltip term_id="node" text="Nodes">}} and provide +{{< glossary_tooltip term_id="pod" text="Pods ">}} with access to resources, +such as local hardware, that require vendor-specific initialization or setup +steps. -[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor-specific resource. Device Plugins advertise these resources to {{< glossary_tooltip term_id="kubelet" >}}. They can be deployed manually or as a {{< glossary_tooltip term_id="daemonset" >}}, rather than writing custom Kubernetes code. +Device plugins advertise resources to the +{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, so that workload +Pods can access hardware features that relate to the Node where that Pod is running. +You can deploy a device plugin as a {{< glossary_tooltip term_id="daemonset" >}}, +or install the device plugin software directly on each target Node. + +See +[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +for more information. diff --git a/content/en/docs/reference/glossary/service-account.md b/content/en/docs/reference/glossary/service-account.md index f5d6854ad0..aee24891c8 100755 --- a/content/en/docs/reference/glossary/service-account.md +++ b/content/en/docs/reference/glossary/service-account.md @@ -15,5 +15,5 @@ tags: -When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. +When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. diff --git a/content/en/docs/reference/glossary/upstream.md b/content/en/docs/reference/glossary/upstream.md index 860e002bfe..880f43562b 100755 --- a/content/en/docs/reference/glossary/upstream.md +++ b/content/en/docs/reference/glossary/upstream.md @@ -14,6 +14,6 @@ tags: -* In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools relies upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool. +* In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools rely upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool. * In **GitHub** or **git**: The convention is to refer to a source repo as *upstream*, whereas the forked repo is considered *downstream*. diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index ba3d48b638..adb7fb8b6f 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -144,7 +144,7 @@ EOF # Get commands with basic output kubectl get services # List all services in the namespace kubectl get pods --all-namespaces # List all pods in all namespaces -kubectl get pods -o wide # List all pods in the namespace, with more details +kubectl get pods -o wide # List all pods in the current namespace, with more details kubectl get deployment my-dep # List a particular deployment kubectl get pods # List all pods in the namespace kubectl get pod my-pod -o yaml # Get a pod's YAML @@ -160,8 +160,8 @@ kubectl get services --sort-by=.metadata.name # List pods Sorted by Restart Count kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# List PersistentVolumes in test namespace sorted by capacity -kubectl get pv -n test --sort-by=.spec.capacity.storage +# List PersistentVolumes sorted by capacity +kubectl get pv --sort-by=.spec.capacity.storage # Get the version label of all pods with label app=cassandra kubectl get pods --selector=app=cassandra -o \ @@ -201,7 +201,7 @@ kubectl diff -f ./my-manifest.yaml ## Updating Resources -As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead. +As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. ```bash kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md index ffbe7103c8..731af0004e 100644 --- a/content/en/docs/reference/kubectl/jsonpath.md +++ b/content/en/docs/reference/kubectl/jsonpath.md @@ -89,11 +89,13 @@ kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}" kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}' ``` +{{< note >}} On Windows, you must _double_ quote any JSONPath template that contains spaces (not single quote as shown above for bash). This in turn means that you must use a single quote or escaped double quote around any literals in the template. For example: ```cmd -C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" -C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" ``` +{{< /note >}} {{% /capture %}} diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index 67d73482ac..6468a5ed70 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -10,7 +10,7 @@ card: --- {{% capture overview %}} -Kubectl is a command line interface for running commands against Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. +Kubectl is a command line tool for controlling Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/). @@ -343,9 +343,6 @@ kubectl delete -f pod.yaml # Delete all the pods and services that have the label name=. kubectl delete pods,services -l name= -# Delete all the pods and services that have the label name=. -kubectl delete pods,services -l name= - # Delete all pods, including uninitialized ones. kubectl delete pods --all ``` diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index c6dd77ee5b..8b82d7da26 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -334,16 +334,16 @@ are not vulnerable to ordering changes in the list. Once the last finalizer is removed, the resource is actually removed from etcd. -## Dry run +## Dry-run -{{< feature-state for_k8s_version="v1.13" state="beta" >}} In version 1.13, the dry run beta feature is enabled by default. The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response. The system guarantees that dry run requests will not be persisted in storage or have any other side effects. +{{< feature-state for_k8s_version="v1.13" state="beta" >}} In version 1.13, the dry-run beta feature is enabled by default. The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry-run mode. DryRun mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non-dry-run response. The system guarantees that dry-run requests will not be persisted in storage or have any other side effects. -### Make a dry run request +### Make a dry-run request -Dry run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.13 the only accepted values are: +Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.13 the only accepted values are: -* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry run requests. +* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests. * Leave the value empty, which is also the default: Keep the default modifying behavior. For example: @@ -352,12 +352,28 @@ For example: Content-Type: application/json Accept: application/json -The response would look the same as for non dry run request, but the values of some generated fields may differ. +The response would look the same as for non-dry-run request, but the values of some generated fields may differ. +### Dry-run authorization + +Authorization for dry-run and non-dry-run requests is identical. Thus, to make +a dry-run request, the user must be authorized to make the non-dry-run request. + +For example, to run a dry-run `PATCH` for Deployments, you must have the +`PATCH` permission for Deployments, as in the example of the RBAC rule below. + +```yaml +rules: +- apiGroups: ["extensions", "apps"] + resources: ["deployments"] + verbs: ["patch"] +``` + +See [Authorization Overview](/docs/reference/access-authn-authz/authorization/). ### Generated values -Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry run request, since these values will likely be different in dry run mode from when the real request is made. Some of these fields are: +Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry-run request, since these values will likely be different in dry-run mode from when the real request is made. Some of these fields are: * `name`: if `generateName` is set, `name` will have a unique random name * `creationTimestamp`/`deletionTimestamp`: records the time of creation/deletion @@ -557,14 +573,22 @@ more information about how an object's schema is used to make decisions when merging, see [sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff). +A number of markers were added in Kubernetes 1.16 and 1.17, to allow API developers to describe the merge strategy supported by lists, maps, and structs. These markers can be applied to objects of the respective type, in Go files or OpenAPI specs. + +| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in | +|---|---|---|---|---| +| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16 | +| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 | +| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 | +| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 | + ### Custom Resources By default, Server Side Apply treats custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. -If the validation field is specified in the Custom Rseource Definition, it is +If the validation field is specified in the Custom Resource Definition, it is used when merging objects of this type. - ### Using Server-Side Apply in a controller As a developer of a controller, you can use server-side apply as a way to @@ -667,32 +691,33 @@ For get and list, the semantics of resource version are: **Get:** -| resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" | -|-----------------------|---------------------|--------------------------------------| -| Most Recent | Any | Not older than | +| resourceVersion unset | resourceVersion is `0` | resourceVersion is set but not `0` | +|-----------------------|------------------------|------------------------------------| +| Most Recent | Any | Not older than | **List:** -| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" | -|-----------|-----------------------|---------------------|--------------------------------------| -| no limit | Most Recent | Any | Not older than | -| limit="n" | Most Recent | Any | Exact | - +| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" | +|-------------------------------|-----------------------|------------------------------------------------|----------------------------------------| +| limit unset | Most Recent | Any | Not older than | +| limit="n", continue unset | Most Recent | Any | Exact | +| limit="n", continue="" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request` | The meaning of the get and list semantics are: - **Most Recent:** Return data at the most recent resource version. The returned data must be consistent (i.e. served from etcd via a quorum read). -- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availability configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic. -- **Not older than:** Return data at least as new as the provided resource version. The newest available resource version is preferred, but any data not older than this resource version may be served. +- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic. +- **Not older than:** Return data at least as new as the provided resource version. The newest available data is preferred, but any data not older than this resource version may be served. Note that this ensures only that the objects returned are no older than they were at the time of the provided resource version. The resource version in the `ObjectMeta` of individual object may be older than the provide resource version so long it is for the latest modification to the object at the time of the provided resource version. - **Exact:** Return data at the exact resource version provided. +- **Continue Token, Exact:** Return data at the resource version of the initial paginated list call. The returned Continue Tokens are responsible for keeping track of the initially provided resource version for all paginated list calls after the initial paginated list call. For watch, the semantics of resource version are: **Watch:** -| resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" | -|-------------------------------------|----------------------------|--------------------------------------| -| Get State and Start at Most Recent | Get State and Start at Any | Start at Exact | +| resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" | +|-------------------------------------|----------------------------|----------------------------------------| +| Get State and Start at Most Recent | Get State and Start at Any | Start at Exact | The meaning of the watch semantics are: @@ -704,4 +729,8 @@ The meaning of the watch semantics are: Servers are not required to serve all older resource versions and may return a HTTP `410 (Gone)` status code if a client requests a resourceVersion older than the server has retained. Clients must be able to tolerate `410 (Gone)` responses. See [Efficient detection of changes](#efficient-detection-of-changes) for details on how to handle `410 (Gone)` responses when watching resources. -For example, the kube-apiserver periodically compacts old resource versions from etcd based on its `--etcd-compaction-interval` setting. Also, the kube-apiserver's watch cache keeps `--watch-cache-sizes` resource versions in each resource cache. It depends on if a request is served from cache on which one of these limits applies, but if a resource version is unavailable in the one that applies, a `410 (Gone)` will be returned by the kube-apiserver. +If you request a a resourceVersion outside the applicable limit then, depending on whether a request is served from cache or not, the API server may reply with a `410 Gone` HTTP response. + +### Unavailable resource versions + +Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a resonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for a unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available. diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index c640a01890..28ed6e1fcf 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -41,7 +41,7 @@ If you're learning Kubernetes, use the Docker-based solutions: tools supported b |Community |Ecosystem | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | @@ -83,7 +83,7 @@ The following production environment solutions table lists the providers and the | [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | | [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | -| [Hidora](https:/hidora.com/) | ✔ | ✔| ✔ | | | | | | | | +| [Hidora](https://hidora.com/) | ✔ | ✔| ✔ | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | | [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md index 1111305068..6169b3f872 100644 --- a/content/en/docs/setup/best-practices/certificates.md +++ b/content/en/docs/setup/best-practices/certificates.md @@ -92,7 +92,7 @@ Hosts/SAN listed above are the recommended ones for getting a working cluster; i For kubeadm users only: * The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation. -* If you are comparing the above list with a kubeadm geneerated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates +* If you are comparing the above list with a kubeadm generated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates are not generated in case of external etcd. {{< /note >}} diff --git a/content/en/docs/setup/learning-environment/kind.md b/content/en/docs/setup/learning-environment/kind.md new file mode 100644 index 0000000000..e476d220d0 --- /dev/null +++ b/content/en/docs/setup/learning-environment/kind.md @@ -0,0 +1,23 @@ +--- +title: Installing Kubernetes with Kind +weight: 40 +content_template: templates/concept +--- + +{{% capture overview %}} + +Kind is a tool for running local Kubernetes clusters using Docker container "nodes". + +{{% /capture %}} + +{{% capture body %}} + +## Installation + +See [Installing Kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +{{% /capture %}} + + + + diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index 3135a6af30..7233f98c0b 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -205,7 +205,11 @@ plugins. * hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`. * vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (Runs the Kubernetes components on the host and not in a VM. It is not recommended to run the none driver on personal workstations. Using this driver requires Docker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) and a Linux environment) +* none (Runs the Kubernetes components on the host and not in a virtual machine. You need to be running Linux and to have {{< glossary_tooltip term_id="docker" >}} installed.) + +{{< caution >}} +If you use the `none` driver, some Kubernetes components run as privileged containers that have side effects outside of the Minikube environment. Those side effects mean that the `none` driver is not recommended for personal workstations. +{{< /caution >}} #### Starting a cluster on alternative container runtimes You can start Minikube on the following container runtimes. @@ -263,11 +267,7 @@ When using a single VM for Kubernetes, it's useful to reuse Minikube's built-in Be sure to tag your Docker image with something other than latest and use that tag to pull the image. Because `:latest` is the default value, with a corresponding default image pull policy of `Always`, an image pull error (`ErrImagePull`) eventually results if you do not have the Docker image in the default Docker registry (usually DockerHub). {{< /note >}} -To work with the Docker daemon on your Mac/Linux host, use the `docker-env command` in your shell: - -```shell -eval $(minikube docker-env) -``` +To work with the Docker daemon on your Mac/Linux host, run the last line from `minikube docker-env`. You can now use Docker at the command line of your host Mac/Linux machine to communicate with the Docker daemon inside the Minikube VM: diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 853256bfb6..704a2728c5 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -74,8 +74,8 @@ Use the following commands to install Docker on your system: # Install Docker CE ## Set up the repository: ### Install packages to allow apt to use a repository over HTTPS -apt-get update && apt-get install \ - apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Add Docker’s official GPG key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - @@ -87,7 +87,7 @@ add-apt-repository \ stable" ## Install Docker CE. -apt-get update && apt-get install \ +apt-get update && apt-get install -y \ containerd.io=1.2.10-3 \ docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) @@ -115,14 +115,14 @@ systemctl restart docker # Install Docker CE ## Set up the repository ### Install required packages. -yum install yum-utils device-mapper-persistent-data lvm2 +yum install -y yum-utils device-mapper-persistent-data lvm2 ### Add Docker repository. yum-config-manager --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo ## Install Docker CE. -yum update && yum install \ +yum update -y && yum install -y \ containerd.io-1.2.10 \ docker-ce-19.03.4 \ docker-ce-cli-19.03.4 @@ -183,13 +183,13 @@ sysctl --system # Install prerequisites apt-get update -apt-get install software-properties-common +apt-get install -y software-properties-common add-apt-repository ppa:projectatomic/ppa apt-get update # Install CRI-O -apt-get install cri-o-1.15 +apt-get install -y cri-o-1.15 {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} @@ -198,7 +198,7 @@ apt-get install cri-o-1.15 yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ # Install CRI-O -yum install --nogpgcheck cri-o +yum install --nogpgcheck -y cri-o {{< /tab >}} {{< /tabs >}} @@ -272,7 +272,7 @@ systemctl restart containerd # Install containerd ## Set up the repository ### Install required packages -yum install yum-utils device-mapper-persistent-data lvm2 +yum install -y yum-utils device-mapper-persistent-data lvm2 ### Add docker repository yum-config-manager \ @@ -280,7 +280,7 @@ yum-config-manager \ https://download.docker.com/linux/centos/docker-ce.repo ## Install containerd -yum update && yum install containerd.io +yum update -y && yum install -y containerd.io # Configure containerd mkdir -p /etc/containerd diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 46290693fc..bfb26fa1ca 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -269,8 +269,7 @@ kubeadm only supports Container Network Interface (CNI) based networks (and does Several projects provide Kubernetes Pod networks using CNI, some of which also support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons. -- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). -- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. +- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). See each plugin's documentation to see if it supports IPv6. Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/). Make sure that your network manifest supports RBAC. @@ -290,12 +289,12 @@ Below you can find installation instructions for some popular Pod network plugin {{< tabs name="tabs-pod-install" >}} {{% tab name="Calico" %}} -For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources. +[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`. -For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64`, `arm64`, and `ppc64le` only. +By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the kubeadm init command using the `--pod-network-cidr=192.168.0.0/16` flag or via the kubeadm configuration. ```shell -kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml +kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml ``` {{% /tab %}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index ffa8229b6e..b768e13323 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -140,7 +140,7 @@ If the container runtime of choice is Docker, it is used through the built-in Other CRI-based runtimes include: -- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd) +- [containerd/cri](https://github.com/containerd/cri) (CRI plugin built into containerd) - [cri-o](https://cri-o.io/) - [frakti](https://github.com/kubernetes/frakti) diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 490cfef8c6..8187d5eac4 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -62,9 +62,9 @@ Kubespray provides the ability to customize many aspects of the deployment: * Component versions * Calico route reflectors * Component runtime options - * docker - * rkt - * cri-o + * {{< glossary_tooltip term_id="docker" >}} + * {{< glossary_tooltip term_id="rkt" >}} + * {{< glossary_tooltip term_id="cri-o" >}} * Certificate generation methods (**Vault being discontinued**) Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md index 60d49c0f3a..c1ad709781 100644 --- a/content/en/docs/setup/release/notes.md +++ b/content/en/docs/setup/release/notes.md @@ -105,7 +105,7 @@ The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migra #### Storage -- All nodes need to be drained before upgrading Kubernetes cluster, because paths used for block volumes are changed in this release, so on-line upgrade of nodes aren't allowed. ([#74026](https://github.com/kubernetes/kubernetes/pull/74026), [@mkimuram](https://github.com/mkimuram)) +- A node that uses a CSI raw block volume needs to be drained before kubelet can be upgraded to 1.17. ([#74026](https://github.com/kubernetes/kubernetes/pull/74026), [@mkimuram](https://github.com/mkimuram)) #### Windows diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index 2760933c0a..ef5f904079 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -207,7 +207,7 @@ The Kubernetes apiserver has two client CA options: Each of these functions independently and can conflict with each other, if not used correctly. -* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentaton on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs). +* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentation on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs). * `--requestheader-client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file reference by `--requestheader-client-ca-file`, then the request is treated as a potentially legitimate request. The Kubernetes apiserver then checks if the common name `CN=` is one of the names in the list provided by `--requestheader-allowed-names`. If the name is allowed, the request is approved; if it is not, the request is not. If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver. diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md index 35d0e2bb60..f730fb3660 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md @@ -5,6 +5,7 @@ reviewers: - liggitt content_template: templates/task weight: 30 +min-kubernetes-server-version: v1.16 --- {{% capture overview %}} @@ -16,11 +17,11 @@ level of your CustomResourceDefinitions or advance your API to a new version wit {{% capture prerequisites %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} -* Make sure your Kubernetes cluster has a master version of 1.16.0 or higher for `apiextensions.k8s.io/v1`, or 1.11.0 or higher for `apiextensions.k8s.io/v1beta1`. +You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/). -* Read about [custom resources](/docs/concepts/api-extension/custom-resources/). +{{< version-check >}} {{% /capture %}} @@ -28,8 +29,6 @@ level of your CustomResourceDefinitions or advance your API to a new version wit ## Overview -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} - The CustomResourceDefinition API provides a workflow for introducing and upgrading to new versions of a CustomResourceDefinition. diff --git a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md index 62a2fe5603..be282a29c1 100644 --- a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md +++ b/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md @@ -38,6 +38,8 @@ Get the API versions: curl http://localhost:8080/api/ +The output should look similar to this: + { "kind": "APIVersions", "versions": [ @@ -55,6 +57,8 @@ Get a list of pods: curl http://localhost:8080/api/v1/namespaces/default/pods +The output should look similar to this: + { "kind": "PodList", "apiVersion": "v1", diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index 97aef1769d..a7ac4d80c9 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -43,7 +43,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s - This list also includes the name of the claims that are bound to each volume + This list also includes the name of the claims that are bound to each volume for easier identification of dynamically provisioned volumes. 1. Choose one of your PersistentVolumes and change its reclaim policy: @@ -54,6 +54,15 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to where `` is the name of your chosen PersistentVolume. + {{< note >}} + On Windows, you must _double_ quote any JSONPath template that contains spaces (not single quote as shown above for bash). This in turn means that you must use a single quote or escaped double quote around any literals in the template. For example: + +```cmd +kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}" +``` + + {{< /note >}} + 1. Verify that your chosen PersistentVolume has the right policy: ```shell diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md index d576493dd3..73cecd999b 100644 --- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -215,8 +215,8 @@ etcd2 and etcd3 is as follows: message `etcd2 is no longer a supported storage backend` Before upgrading a v1.12.x kube-apiserver using `--storage-backend=etcd2` to -v1.13.x, etcd v2 data MUST by migrated to the v3 storage backend, and -kube-apiserver invocations changed to use `--storage-backend=etcd3`. +v1.13.x, etcd v2 data must be migrated to the v3 storage backend and +kube-apiserver invocations must be changed to use `--storage-backend=etcd3`. The process for migrating from etcd2 to etcd3 is highly dependent on how the etcd cluster was deployed and configured, as well as how the Kubernetes diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md index 597b1cf737..352a709386 100644 --- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -258,14 +258,7 @@ Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. This should probably be implemented eventually. -Linux's libc is impossibly stuck ([see this bug from -2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just -3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to -consume 1 `nameserver` record and 3 `search` records. This means that if a -local installation already uses 3 `nameserver`s or uses more than 3 `search`es, -some of those settings will be lost. As a partial workaround, the node can run -`dnsmasq` which will provide more `nameserver` entries, but not more `search` -entries. You can also use kubelet's `--resolv-conf` flag. +Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glic-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc versions in the affected list, some of those settings will be lost. For the workaround of the DNS `nameserver` records limit, the node can run `dnsmasq` which will provide more `nameserver` entries, you can also use kubelet's `--resolv-conf` flag. For fixing the DNS `search` records limit, consider upgrading your linux distribution or glibc version. If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly owing to a known issue with Alpine. diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 2cddad2d72..5d5dc98ade 100644 --- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -97,7 +97,7 @@ kubectl apply -f dns-horizontal-autoscaler.yaml The output of a successful command is: - deployment.apps/kube-dns-autoscaler created + deployment.apps/dns-autoscaler created DNS horizontal autoscaling is now enabled. diff --git a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md new file mode 100644 index 0000000000..c39b9b366d --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md @@ -0,0 +1,54 @@ +--- +reviewers: +- andrewsykim +- johnbelamaric +- imroc +title: Enabling Service Topology +content_template: templates/task +--- + +{{% capture overview %}} +This page provides an overview of enabling Service Topology in Kubernetes. +{{% /capture %}} + + +{{% capture prerequisites %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{% /capture %}} + +{{% capture steps %}} + +## Introduction + +_Service Topology_ enables a service to route traffic based upon the Node +topology of the cluster. For example, a service can specify that traffic be +preferentially routed to endpoints that are on the same Node as the client, or +in the same availability zone. + +## Prerequisites + +The following prerequisites are needed in order to enable topology aware service +routing: + + * Kubernetes 1.17 or later + * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}} running in iptables mode or IPVS mode + * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) + +## Enable Service Topology + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +To enable service topology, enable the `ServiceTopology` and `EndpointSlice` feature gate for all Kubernetes components: + +``` +--feature-gates="ServiceTopology=true,EndpointSlice=true" +``` + + +{{% capture whatsnext %}} + +* Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept +* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices) +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) + +{{% /capture %}} diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 988c5b630e..920fe19197 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -3,6 +3,7 @@ reviewers: - smarterclayton title: Encrypting Secret Data at Rest content_template: templates/task +min-kubernetes-server-version: 1.13 --- {{% capture overview %}} @@ -13,9 +14,7 @@ This page shows how to enable and configure encryption of secret data at rest. * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* Kubernetes version 1.13.0 or later is required - -* etcd v3 or later is required +* etcd v3.0 or later is required {{% /capture %}} @@ -27,9 +26,6 @@ The `kube-apiserver` process accepts an argument `--encryption-provider-config` that controls how API data is encrypted in etcd. An example configuration is provided below. -Note: -The alpha version of the encryption feature prior to 1.13 used the `--experimental-encryption-provider-config` flag. - ## Understanding the encryption at rest configuration. ```yaml @@ -69,10 +65,6 @@ resources from storage each provider that matches the stored data attempts to de order. If no provider can read the stored data due to a mismatch in format or secret key, an error is returned which prevents clients from accessing that resource. -Note: -The alpha version of the encryption feature prior to 1.13 required to be configured with -`kind: EncryptionConfig` and `apiVersion: v1`. - {{< caution >}} **IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to @@ -81,11 +73,12 @@ read that resource will fail until it is deleted or a valid decryption key is pr ### Providers: +{{< table caption="Providers for Kubernetes encryption at rest" >}} Name | Encryption | Strength | Speed | Key Length | Other Considerations -----|------------|----------|-------|------------|--------------------- `identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written. `aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`. -`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review. +`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review. `aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented. `kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/) @@ -95,12 +88,12 @@ is the first provider, the first key is used for encryption. __Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption. Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key. + Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise. Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and -extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption -creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the -kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than -locally-stored encryption keys. +extract the encryption keys. + +Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than locally-stored encryption keys. ## Encrypting your data @@ -137,7 +130,7 @@ Your config file contains keys that can decrypt content in etcd, so you must pro {{< /caution >}} -## Verifying that data is encrypted +## Verifying that data is encrypted Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line @@ -217,5 +210,3 @@ and restart all `kube-apiserver` processes. Then run the command `kubectl get se to force all secrets to be decrypted. {{% /capture %}} - - diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 9c81f3b488..83bb8f3379 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -4,17 +4,20 @@ reviewers: - dawnchen title: Reconfigure a Node's Kubelet in a Live Cluster content_template: templates/task +min-kubernetes-server-version: v1.11 --- {{% capture overview %}} {{< feature-state for_k8s_version="v1.11" state="beta" >}} [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281) -allows you to change the configuration of each Kubelet in a live Kubernetes -cluster by deploying a ConfigMap and configuring each Node to use it. +allows you to change the configuration of each +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} in a running Kubernetes cluster, +by deploying a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} and configuring +each {{< glossary_tooltip term_id="node" >}} to use it. {{< warning >}} -All Kubelet configuration parameters can be changed dynamically, +All kubelet configuration parameters can be changed dynamically, but this is unsafe for some parameters. Before deciding to change a parameter dynamically, you need a strong understanding of how that change will affect your cluster's behavior. Always carefully test configuration changes on a small set @@ -25,38 +28,49 @@ fields is available in the inline `KubeletConfiguration` {{% /capture %}} {{% capture prerequisites %}} -- Kubernetes v1.11 or higher on both the Master and the Nodes -- kubectl v1.11 or higher, configured to communicate with the cluster -- The Kubelet's `--dynamic-config-dir` flag must be set to a writable - directory on the Node. +You need to have a Kubernetes cluster. +You also need kubectl v1.11 or higher, configured to communicate with your cluster. +{{< version-check >}} +Your cluster API server version (eg v1.12) must be no more than one minor +version away from the version of kubectl that you are using. For example, +if your cluster is running v1.16 then you can use kubectl v1.15, v1.16 +or v1.17; other combinations +[aren't supported](/docs/setup/release/version-skew-policy/#kubectl). + +Some of the examples use the commandline tool +[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task, +because there are manual alternatives. + +For each node that you're reconfiguring, you must set the kubelet +`--dynamic-config-dir` flag to a writable directory. {{% /capture %}} {{% capture steps %}} -## Reconfiguring the Kubelet on a Live Node in your Cluster +## Reconfiguring the kubelet on a running node in your cluster -### Basic Workflow Overview +### Basic workflow overview -The basic workflow for configuring a Kubelet in a live cluster is as follows: +The basic workflow for configuring a kubelet in a live cluster is as follows: 1. Write a YAML or JSON configuration file containing the -Kubelet's configuration. +kubelet's configuration. 2. Wrap this file in a ConfigMap and save it to the Kubernetes control plane. -3. Update the Kubelet's corresponding Node object to use this ConfigMap. +3. Update the kubelet's corresponding Node object to use this ConfigMap. -Each Kubelet watches a configuration reference on its respective Node object. -When this reference changes, the Kubelet downloads the new configuration, +Each kubelet watches a configuration reference on its respective Node object. +When this reference changes, the kubelet downloads the new configuration, updates a local reference to refer to the file, and exits. For the feature to work correctly, you must be running an OS-level service -manager (such as systemd), which will restart the Kubelet if it exits. When the -Kubelet is restarted, it will begin using the new configuration. +manager (such as systemd), which will restart the kubelet if it exits. When the +kubelet is restarted, it will begin using the new configuration. The new configuration completely overrides configuration provided by `--config`, and is overridden by command-line flags. Unspecified values in the new configuration will receive default values appropriate to the configuration version (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags. -The status of the Node's Kubelet configuration is reported via +The status of the Node's kubelet configuration is reported via `Node.Spec.Status.Config`. Once you have updated a Node to use the new ConfigMap, you can observe this status to confirm that the Node is using the intended configuration. @@ -70,7 +84,7 @@ mind that it is also valid for multiple Nodes to consume the same ConfigMap. {{< warning >}} While it is *possible* to change the configuration by -updating the ConfigMap in-place, this causes all Kubelets configured with +updating the ConfigMap in-place, this causes all kubelets configured with that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps as immutable by convention, aided by `kubectl`'s `--append-hash` option, and incrementally roll out updates to `Node.Spec.ConfigSource`. @@ -91,23 +105,35 @@ and debug issues. The compromise, however, is that you must start with knowledge of the existing configuration to ensure that you only change the fields you intend to change. -Ideally, the Kubelet would be bootstrapped from a file on disk -and you could edit this file (which could also be version-controlled), -to create the first Kubelet ConfigMap -(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)), -Currently, the Kubelet is bootstrapped with **a combination of this file and command-line flags** -that can override the configuration in the file. -As a workaround, you can generate a config file containing a Node's current -configuration by accessing the Kubelet server's `configz` endpoint via the -kubectl proxy. This endpoint, in its current implementation, is intended to be -used only as a debugging aid. Do not rely on the behavior of this endpoint for -production scenarios. The examples below use the `jq` command to streamline -working with JSON. To follow the tasks as written, you need to have `jq` -installed, but you can adapt the tasks if you prefer to extract the -`kubeletconfig` subobject manually. +The kubelet loads settings from its configuration file, but you can set command +line flags to override the configuration in the file. This means that if you +only know the contents of the configuration file, and you don't know the +command line overrides, then you do not know the running configuration either. + +Because you need to know the running configuration in order to override it, +you can fetch the running configuration from the kubelet. You can generate a +config file containing a Node's current configuration by accessing the kubelet's +`configz` endpoint, through `kubectl proxy`. The next section explains how to +do this. + +{{< caution >}} +The kubelet's `configz` endpoint is there to help with debugging, and is not +a stable part of kubelet behavior. +Do not rely on the behavior of this endpoint for production scenarios or for +use with automated tools. +{{< /caution >}} + +For more information on configuring the kubelet via a configuration file, see +[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)). #### Generate the configuration file +{{< note >}} +The steps below use the `jq` command to streamline working with JSON. +To follow the tasks as written, you need to have `jq` installed. You can +adapt the steps if you prefer to extract the `kubeletconfig` subobject manually. +{{< /note >}} + 1. Choose a Node to reconfigure. In this example, the name of this Node is referred to as `NODE_NAME`. 2. Start the kubectl proxy in the background using the following command: @@ -122,20 +148,22 @@ installed, but you can adapt the tasks if you prefer to extract the For example: `${NODE_NAME}` will be rewritten as `$\{NODE_NAME\}` during the paste. You must remove the backslashes before running the command, or the command will fail. + ```bash NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME} ``` {{< note >}} You need to manually add the `kind` and `apiVersion` to the downloaded -object, because they are not reported by the `configz` endpoint. +object, because those fields are not reported by the `configz` endpoint. {{< /note >}} #### Edit the configuration file Using a text editor, change one of the parameters in the file generated by the previous procedure. For example, you -might edit the QPS parameter `eventRecordQPS`. +might edit the parameter `eventRecordQPS`, that controls +rate limiting for event recording. #### Push the configuration file to the control plane @@ -162,12 +190,12 @@ data: {...} ``` -The ConfigMap is created in the `kube-system` namespace because this -ConfigMap configures a Kubelet, which is Kubernetes system component. +You created that ConfigMap inside the `kube-system` namespace because the kubelet +is a Kubernetes system component. The `--append-hash` option appends a short checksum of the ConfigMap contents to the name. This is convenient for an edit-then-push workflow, because it -automatically, yet deterministically, generates new names for new ConfigMaps. +automatically, yet deterministically, generates new names for new resources. The name that includes this generated hash is referred to as `CONFIG_MAP_NAME` in the following examples. @@ -185,13 +213,13 @@ In your text editor, add the following YAML under `spec`: ```yaml configSource: configMap: - name: CONFIG_MAP_NAME + name: CONFIG_MAP_NAME # replace CONFIG_MAP_NAME with the name of the ConfigMap namespace: kube-system kubeletConfigKey: kubelet ``` You must specify all three of `name`, `namespace`, and `kubeletConfigKey`. -The `kubeletConfigKey` parameter shows the Kubelet which key of the ConfigMap +The `kubeletConfigKey` parameter shows the kubelet which key of the ConfigMap contains its config. #### Observe that the Node begins using the new configuration @@ -200,16 +228,16 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and `Node.Status.Config`. The config sources corresponding to the `active`, `assigned`, and `lastKnownGood` configurations are reported in the status. -- The `active` configuration is the version the Kubelet is currently running with. -- The `assigned` configuration is the latest version the Kubelet has resolved based on +- The `active` configuration is the version the kubelet is currently running with. +- The `assigned` configuration is the latest version the kubelet has resolved based on `Node.Spec.ConfigSource`. - The `lastKnownGood` configuration is the version the - Kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`. + kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`. The`lastKnownGood` configuration might not be present if it is set to its default value, the local config deployed with the node. The status will update `lastKnownGood` to -match a valid `assigned` config after the Kubelet becomes comfortable with the config. -The details of how the Kubelet determines a config should become the `lastKnownGood` are +match a valid `assigned` config after the kubelet becomes comfortable with the config. +The details of how the kubelet determines a config should become the `lastKnownGood` are not guaranteed by the API, but is currently implemented as a 10-minute grace period. You can use the following command (using `jq`) to filter down @@ -254,16 +282,19 @@ The following is an example response: ``` -If an error occurs, the Kubelet reports it in the `Node.Status.Config.Error` +(if you do not have `jq`, you can look at the whole response and find `Node.Status.Config` +by eye). + +If an error occurs, the kubelet reports it in the `Node.Status.Config.Error` structure. Possible errors are listed in [Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages). -You can search for the identical text in the Kubelet log for additional details +You can search for the identical text in the kubelet log for additional details and context about the error. #### Make more changes Follow the workflow above to make more changes and push them again. Each time -you push a ConfigMap with new contents, the --append-hash kubectl option creates +you push a ConfigMap with new contents, the `--append-hash` kubectl option creates the ConfigMap with a new name. The safest rollout strategy is to first create a new ConfigMap, and then update the Node to use the new ConfigMap. @@ -283,7 +314,7 @@ error is reported. {{% /capture %}} {{% capture discussion %}} -## Kubectl Patch Example +## `kubectl patch` example You can change a Node's configSource using several different mechanisms. This example uses `kubectl patch`: @@ -292,25 +323,25 @@ This example uses `kubectl patch`: kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}" ``` -## Understanding how the Kubelet checkpoints config +## Understanding how the kubelet checkpoints config -When a new config is assigned to the Node, the Kubelet downloads and unpacks the -config payload as a set of files on the local disk. The Kubelet also records metadata +When a new config is assigned to the Node, the kubelet downloads and unpacks the +config payload as a set of files on the local disk. The kubelet also records metadata that locally tracks the assigned and last-known-good config sources, so that the -Kubelet knows which config to use across restarts, even if the API server becomes -unavailable. After checkpointing a config and the relevant metadata, the Kubelet -exits if it detects that the assigned config has changed. When the Kubelet is +kubelet knows which config to use across restarts, even if the API server becomes +unavailable. After checkpointing a config and the relevant metadata, the kubelet +exits if it detects that the assigned config has changed. When the kubelet is restarted by the OS-level service manager (such as `systemd`), it reads the new metadata and uses the new config. The recorded metadata is fully resolved, meaning that it contains all necessary information to choose a specific config version - typically a `UID` and `ResourceVersion`. This is in contrast to `Node.Spec.ConfigSource`, where the intended config is declared -via the idempotent `namespace/name` that identifies the target ConfigMap; the Kubelet +via the idempotent `namespace/name` that identifies the target ConfigMap; the kubelet tries to use the latest version of this ConfigMap. -When you are debugging problems on a node, you can inspect the Kubelet's config -metadata and checkpoints. The structure of the Kubelet's checkpointing directory is: +When you are debugging problems on a node, you can inspect the kubelet's config +metadata and checkpoints. The structure of the kubelet's checkpointing directory is: ```none - --dynamic-config-dir (root for managing dynamic config) @@ -334,13 +365,18 @@ in the Kubelet log for additional details and context about the error. Error Message | Possible Causes :-------------| :-------------- -failed to load config, see Kubelet log for details | The Kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk. -failed to validate config, see Kubelet log for details | The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the Kubelet. -invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the Kubelet is older than the API server and does not recognize a newer source type. -failed to sync: failed to download config, see Kubelet log for details | The Kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The Kubelet will retry the download when in this error state. -failed to sync: internal failure, see Kubelet log for details | The Kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache. -internal failure, see Kubelet log for details | The Kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop. +failed to load config, see Kubelet log for details | The kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk. +failed to validate config, see Kubelet log for details | The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the kubelet. +invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the kubelet is older than the API server and does not recognize a newer source type. +failed to sync: failed to download config, see Kubelet log for details | The kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The kubelet will retry the download when in this error state. +failed to sync: internal failure, see Kubelet log for details | The kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache. +internal failure, see Kubelet log for details | The kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop. -{{< /table >}} +{{< /table >}} {{% /capture %}} +{{% capture whatsnext %}} + - For more information on configuring the kubelet via a configuration file, see +[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file). +- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) +{{% /capture %}} diff --git a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md index 83c24f639e..6bdd9a1061 100644 --- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md @@ -77,7 +77,7 @@ Cloud controller manager does not implement any of the volume controllers found ### Scalability -In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting. +In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very large clusters, you should consider possible bottle necks such as resource requirements and API rate limiting. ### Chicken and Egg diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index 12ab6ed22b..dcba78d81a 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -26,7 +26,7 @@ You can use either `kubectl create configmap` or a ConfigMap generator in `kusto ### Create a ConfigMap Using kubectl create configmap -Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values): +Use the `kubectl create configmap` command to create ConfigMaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values): ```shell kubectl create configmap @@ -34,10 +34,7 @@ kubectl create configmap where \ is the name you want to assign to the ConfigMap and \ is the directory, file, or literal value to draw the data from. -The data source corresponds to a key-value pair in the ConfigMap, where - -* key = the file name or the key you provided on the command line, and -* value = the file contents or the literal value you provided on the command line. +When you are creating a ConfigMap based on a file, the key in the \ defaults to the basename of the file, and the value defaults to the file content. You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) or [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information @@ -45,7 +42,7 @@ about a ConfigMap. #### Create ConfigMaps from directories -You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. +You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. When you are creating a ConfigMap based on a directory, kubectl identifies files whose basename is a valid key in the directory and packages each of those files into the new ConfigMap. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc). For example: @@ -61,30 +58,36 @@ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-con kubectl create configmap game-config --from-file=configure-pod-container/configmap/ ``` -combines the contents of the `configure-pod-container/configmap/` directory - -```shell -game.properties -ui.properties -``` - -into the following ConfigMap: +The above command packages each file, in this case, `game.properties` and `ui.properties` in the `configure-pod-container/configmap/` directory into the game-config ConfigMap. You can display details of the ConfigMap using the following command: ```shell kubectl describe configmaps game-config ``` -where the output is similar to this: +The output is similar to this: ``` -Name: game-config -Namespace: default -Labels: -Annotations: +Name: game-config +Namespace: default +Labels: +Annotations: Data ==== -game.properties: 158 bytes -ui.properties: 83 bytes +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice ``` The `game.properties` and `ui.properties` files in the `configure-pod-container/configmap/` directory are represented in the `data` section of the ConfigMap. @@ -138,14 +141,22 @@ kubectl describe configmaps game-config-2 where the output is similar to this: ``` -Name: game-config-2 -Namespace: default -Labels: -Annotations: +Name: game-config-2 +Namespace: default +Labels: +Annotations: Data ==== -game.properties: 158 bytes +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 ``` You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources. @@ -154,7 +165,7 @@ You can pass in the `--from-file` argument multiple times to create a ConfigMap kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties ``` -Describe the above `game-config-2` configmap created +You can display details of the `game-config-2` ConfigMap using the following command: ```shell kubectl describe configmaps game-config-2 @@ -163,15 +174,28 @@ kubectl describe configmaps game-config-2 The output is similar to this: ``` -Name: game-config-2 -Namespace: default -Labels: -Annotations: +Name: game-config-2 +Namespace: default +Labels: +Annotations: Data ==== -game.properties: 158 bytes -ui.properties: 83 bytes +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice ``` Use the option `--from-env-file` to create a ConfigMap from an env-file, for example: @@ -227,11 +251,11 @@ data: When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used. {{< /caution >}} -The behavior of passing `--from-env-file` multiple times is demonstrated by: +The behavior of passing `--from-env-file` multiple times is demonstrated by: ```shell # Download the sample files into `configure-pod-container/configmap/` directory -wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties +wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties # Create the configmap kubectl create configmap config-multi-env-files \ @@ -656,4 +680,3 @@ data: * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/). {{% /capture %}} - diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index f1740d9ae7..56ba566bc6 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -123,6 +123,8 @@ As an example, to look at the logs from a running Cassandra pod, you might run: kubectl exec cassandra -- cat /var/log/cassandra/system.log ``` +If your cluster enabled it, you can also try adding an [ephemeral container](/docs/concepts/workloads/pods/ephemeral-containers/) into the existing pod. You can use the new temporary container to run arbitrary commands, for example, to diagnose problems inside the Pod. See the page about [ephemeral container](/docs/concepts/workloads/pods/ephemeral-containers/) for more details, including feature availability. + If none of these approaches work, you can find the host machine that the pod is running on and SSH into that host. diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md index 7ae9350944..8886da28d2 100644 --- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -2,6 +2,7 @@ title: Distribute Credentials Securely Using Secrets content_template: templates/task weight: 50 +min-kubernetes-server-version: v1.6 --- {{% capture overview %}} @@ -11,7 +12,7 @@ encryption keys, into Pods. {{% capture prerequisites %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} {{% /capture %}} diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index 9327afe2a5..42c47a43b5 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -52,7 +52,7 @@ cronjob.batch/hello created Alternatively, you can use `kubectl run` to create a cron job without writing a full config: ```shell -kubectl run --generator=run-pod/v1 hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster" +kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster" ``` After creating the cron job, get its status using this command: diff --git a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md index 6c396e7861..0dee8eb60a 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -83,7 +83,14 @@ kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` {{< note >}} -`diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run), which needs to be enabled on `kube-apiserver`. +`diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run), +which needs to be enabled on `kube-apiserver`. + +Since `diff` performs a server-side apply request in dry-run mode, +it requires granting `PATCH`, `CREATE`, and `UPDATE` permissions. +See [Dry-Run Authorization](/docs/reference/using-api/api-concepts#dry-run-authorization) +for details. + {{< /note >}} Create the object using `kubectl apply`: @@ -985,11 +992,11 @@ used only by the controller selector with no other semantic meaning. ```yaml selector: matchLabels: - controller-selector: "extensions/v1beta1/deployment/nginx" + controller-selector: "apps/v1/deployment/nginx" template: metadata: labels: - controller-selector: "extensions/v1beta1/deployment/nginx" + controller-selector: "apps/v1/deployment/nginx" ``` {{% capture whatsnext %}} diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md index 1c32e8f834..ec6057cd68 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -135,11 +135,11 @@ Example label: ```yaml selector: matchLabels: - controller-selector: "extensions/v1beta1/deployment/nginx" + controller-selector: "apps/v1/deployment/nginx" template: metadata: labels: - controller-selector: "extensions/v1beta1/deployment/nginx" + controller-selector: "apps/v1/deployment/nginx" ``` {{% /capture %}} diff --git a/content/en/docs/tasks/network/validate-dual-stack.md b/content/en/docs/tasks/network/validate-dual-stack.md index 4d9e6c3969..0e6d586bea 100644 --- a/content/en/docs/tasks/network/validate-dual-stack.md +++ b/content/en/docs/tasks/network/validate-dual-stack.md @@ -14,7 +14,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu {{% capture prerequisites %}} * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) -* Kubenet network plugin +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) * Kube-proxy running in mode IPVS * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster @@ -39,7 +39,7 @@ a00:100::/24 ``` There should be one IPv4 block and one IPv6 block allocated. -Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0): +Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0): ```shell kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}' ``` @@ -151,7 +151,7 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba {{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}} -Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. +Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. ``` kubectl get svc -l app=MyApp NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE @@ -159,4 +159,3 @@ my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:318 ``` {{% /capture %}} - diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index fdcc75d211..6a9fe4de32 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -62,14 +62,19 @@ It defines an index.php page which performs some CPU intensive computations: ?> ``` -First, we will start a deployment running the image and expose it as a service: +First, we will start a deployment running the image and expose it as a service +using the following configuration: +{{< codenew file="application/php-apache.yaml" >}} + + +Run the following command: ```shell -kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80 +kubectl apply -f https://k8s.io/examples/application/php-apache.yaml ``` ``` -service/php-apache created deployment.apps/php-apache created +service/php-apache created ``` ## Create Horizontal Pod Autoscaler diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 2f76954df9..871e5c3494 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -3,7 +3,6 @@ reviewers: - fgrzadkowski - jszczepkowski - directxman12 -- josephburnett title: Horizontal Pod Autoscaler feature: title: Horizontal scaling @@ -163,15 +162,11 @@ can be fetched, scaling is skipped. This means that the HPA is still capable of scaling up if one or more metrics give a `desiredReplicas` greater than the current value. -Finally, just before HPA scales the target, the scale recommendation is -recorded. The controller considers all recommendations within a configurable -window choosing the highest recommendation from within that window. This value -can be configured using the -`--horizontal-pod-autoscaler-downscale-stabilization` flag or the HPA object -behavior `behavior.scaleDown.stabilizationWindowSeconds` (see [Support for -configurable scaling behavior](#support-for-configurable-scaling-behavior)), -which defaults to 5 minutes. This means that scaledowns will occur gradually, -smoothing out the impact of rapidly fluctuating metric values. +Finally, just before HPA scales the target, the scale recommendation is recorded. The +controller considers all recommendations within a configurable window choosing the +highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes. +This means that scaledowns will occur gradually, smoothing out the impact of rapidly +fluctuating metric values. ## API Object @@ -218,7 +213,10 @@ When managing the scale of a group of replicas using the Horizontal Pod Autoscal it is possible that the number of replicas keeps fluctuating frequently due to the dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*. -Starting from v1.12, a new algorithmic update removes the need for an +Starting from v1.6, a cluster operator can mitigate this problem by tuning +the global HPA settings exposed as flags for the `kube-controller-manager` component: + +Starting from v1.12, a new algorithmic update removes the need for the upscale delay. - `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a @@ -234,11 +232,6 @@ the delay value is set too short, the scale of the replicas set may keep thrashi usual. {{< /note >}} -Starting from v1.17 the downscale stabilization window can be set on a per-HPA -basis by setting the `behavior.scaleDown.stabilizationWindowSeconds` field in -the v2beta2 API. See [Support for configurable scaling -behavior](#support-for-configurable-scaling-behavior). - ## Support for multiple metrics Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 2f1b59d83f..2a6af0af4c 100644 --- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -84,7 +84,7 @@ weight: 10
-

When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.

+

When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.

A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, macOS, and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this tutorial, however, you'll use a provided online terminal with Minikube pre-installed.

diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html index aa6f9b4063..3531cfd3b5 100644 --- a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -31,7 +31,7 @@ weight: 10

Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). - In Kubernetes, updates are versioned and any Deployment update can be reverted to previous (stable) version.

+ In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.

diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index e59f9058a0..e1b4876a24 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -34,7 +34,7 @@ document. The examples use a small nginx webserver that echoes back the source IP of requests it receives through an HTTP header. You can create it as follows: ```console -kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 ``` The output is: ``` diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md index 62f89d35bb..4f4dbda986 100644 --- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -80,8 +80,17 @@ The preceding command creates a NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s - Note: If the external IP address is shown as \, wait for a minute - and enter the same command again. + {{< note >}} + + The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details. + + {{< /note >}} + + {{< note >}} + + If the external IP address is shown as \, wait for a minute and enter the same command again. + + {{< /note >}} 1. Display detailed information about the Service: diff --git a/content/en/docs/user-journeys/users/application-developer/advanced.md b/content/en/docs/user-journeys/users/application-developer/advanced.md deleted file mode 100644 index dde720f1b6..0000000000 --- a/content/en/docs/user-journeys/users/application-developer/advanced.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -reviewers: -- chenopis -layout: docsportal -css: /css/style_user_journeys.css -js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js -title: Advanced Topics -track: "USERS â€ș APPLICATION DEVELOPER â€ș ADVANCED" -content_template: templates/user-journey-content ---- - -{{% capture overview %}} - -{{< note >}} -This page assumes that you're familiar with core Kubernetes concepts, and are comfortable deploying your own apps. If not, you should review the {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} topics first. -{{< /note >}} -After checking out the current page and its linked sections, you should have a better understanding of the following: -* Advanced features that you can leverage in your application -* The various ways of extending the Kubernetes API - -{{% /capture %}} - - -{{% capture body %}} - -## Deploy an application with advanced features - -Now you know the set of API objects that Kubernetes provides. Understanding the difference between a {{< glossary_tooltip term_id="daemonset" >}} and a {{< glossary_tooltip term_id="deployment" >}} is oftentimes sufficient for app deployment. That being said, it's also worth familiarizing yourself with Kubernetes's lesser known features. They can be quite powerful when applied to the right use cases. - -#### Container-level features - -As you may know, it's an antipattern to migrate an entire app (e.g. containerized Rails app, MySQL database, and all) into a single Pod. That being said, there are some very useful patterns that go beyond a 1:1 correspondence between a container and its Pod: - -* **Sidecar container**: Although your Pod should still have a single main container, you can add a secondary container that acts as a helper (see a {{< link text="logging example" url="/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent" >}}). Two containers within a single Pod can communicate {{< link text="via a shared volume" url="/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/" >}}. -* **Init containers**: *Init containers* run before any of a Pod's *app containers* (such as main and sidecar containers). {{< link text="Read more" url="/docs/concepts/workloads/pods/init-containers/" >}}, see an {{< link text="nginx server example" url="/docs/tasks/configure-pod-container/configure-pod-initialization/" >}}, and {{< link text="learn how to debug these containers" url="/docs/tasks/debug-application-cluster/debug-init-containers/" >}}. - -#### Pod configuration - -Usually, you use {{< glossary_tooltip text="labels" term_id="label" >}} and {{< glossary_tooltip text="annotations" term_id="annotation" >}} to attach metadata to your resources. To inject data into your resources, you'd likely create {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} (for nonconfidential data) or {{< glossary_tooltip text="Secrets" term_id="secret" >}} (for confidential data). - -Below are some other, lesser-known ways of configuring your resources' Pods: - -* **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. They are often used when an application needs to be deployed onto specific hardware, such as GPUs for scientific computing. {{< link text="Read more" url="/docs/concepts/configuration/taint-and-toleration/" >}}. -* **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with {{< link text="environment variables" url="/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" >}} or {{< link text="DownwardAPIVolumeFiles" url="/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/" >}}. -* **Pod Presets** - Normally, to mount runtime requirements (such as environmental variables, ConfigMaps, and Secrets) into a resource, you specify them in the resource's configuration file. {{< link text="PodPresets" url="/docs/concepts/workloads/pods/podpreset/" >}} allow you to dynamically inject these requirements instead, when the resource is created. For instance, this allows team A to mount any number of new Secrets into the resources created by teams B and C, without requiring action from B and C. {{< link text="See an example" url="/docs/tasks/inject-data-application/podpreset/" >}}. - -#### Additional API Objects - -{{< note >}} -Before setting up the following resources, check to see if they are the responsibility of your organization's {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}}. -{{< /note >}} -* **{{< glossary_tooltip text="Horizontal Pod Autoscaler (HPA)" term_id="horizontal-pod-autoscaler" >}}** - These resources are a great way to automate the process of scaling your application when CPU usage or other {{< link text="custom metrics" url="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md" >}} spike. {{< link text="See an example" url="/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" >}} to understand how HPAs are set up. - -* **Federated cluster objects** - If you are running an application on multiple Kubernetes clusters using *federation*, you need to deploy the federated version of the standard Kubernetes API objects. For reference, check out the guides for setting up {{< link text="Federated ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="Federated Deployments" url="/docs/tasks/administer-federation/deployment/" >}}. - -## Extend the Kubernetes API - -Kubernetes is designed with extensibility in mind. If the API resources and features mentioned above are not enough for your needs, there are ways to customize its behavior without having to modify core Kubernetes code. - -#### Understand Kubernetes's default behavior - -Before making any customizations, it's important that you understand the general abstraction behind Kubernetes API objects. Although Deployments and Secrets may seem quite different, the following concepts are true for *any* object: - -* **Kubernetes objects are a way of storing structured data about your cluster.** - In the case of Deployments, this data represents desired state (such as "How many replicas should be running?"), but it can also be general metadata (such as database credentials). -* **Kubernetes objects are modified via the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}**. - In other words, you can make `GET` and `POST` requests to a specific resource path (such as `/api/v1/namespaces/default/deployments`) to read and write the corresponding object type. -* **By leveraging the {{< link text="Controller pattern" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}, Kubernetes objects can be used to enforce desired state**. For simplicity, you can think of the Controller pattern as the following continuous loop: - -
- 1. Check current state (number of replicas, container image, etc) - 2. Compare current state to desired state - 3. Update if there's a mismatch -
- - These states are obtained from the Kubernetes API. - - {{< note >}} - Not all Kubernetes objects need to have a Controller. Though Deployments trigger the cluster to make state changes, ConfigMaps act purely as storage. - {{< /note >}} -#### Create Custom Resources - -Based on the ideas above, you can define a new {{< link text="Custom Resource" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need. - -There are two main ways of setting up custom resources: -1. **Custom Resource Definitions (CRDs)** - This method requires the least amount of implementation work. See {{< link text="an example" url="/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/" >}}. -2. **API aggregation** - This method requires some {{< link text="pre-configuration" url="/docs/tasks/access-kubernetes-api/configure-aggregation-layer/" >}} before you actually {{< link text="set up a separate, extension API server" url="/docs/tasks/access-kubernetes-api/setup-extension-api-server/" >}}. - -Note that unlike standard Kubernetes objects, which rely on the built-in {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}, you'll need to write and run your own {{< link text="custom controllers" url="https://github.com/kubernetes/sample-controller" >}}. - -You may also find the following info helpful: -* {{< link text="How to know if custom resources are right for your use case" url="/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource" >}} -* {{< link text="How to decide between CRDs and API aggregation" url="/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources" >}} - -#### Service Catalog - -If you want to consume or provide complete services (rather than individual resources), **{{< glossary_tooltip text="Service Catalog" term_id="service-catalog" >}}** provides a {{< link text="specification" url="https://github.com/openservicebrokerapi/servicebroker" >}} for doing so. These services are registered using {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} (see {{< link text="some examples" url="https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers" >}}). - -If you do not have a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} to manage the installation of Service Catalog, you can do so using {{< link text="Helm" url="/docs/tasks/service-catalog/install-service-catalog-using-helm/" >}} or an {{< link text="installer binary" url="/docs/tasks/service-catalog/install-service-catalog-using-sc/" >}}. - - -## Explore additional resources - -#### References - -The following topics are also useful for building more complex applications: - -* {{< link text="Other points of extensibility within Kubernetes" url="/docs/concepts/overview/extending/" >}} - A conceptual overview of where you can hook into the Kubernetes architecture. -* {{< link text="Kubernetes Client Libraries" url="/docs/reference/using-api/client-libraries/" >}} - Useful for building apps that need to interact heavily with the Kubernetes API. - -#### What's next -Congrats on completing the Application Developer user journey! You've covered the majority of features that Kubernetes has to offer. What now? - -* If you'd like to suggest new features or keep up with the latest developments around Kubernetes app development, consider joining a {{< glossary_tooltip term_id="sig" >}} such as {{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}. - -* If you are interested in learning more about the inner workings of Kubernetes (e.g. networking), consider checking out the {{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}. - -{{% /capture %}} - - diff --git a/content/en/docs/user-journeys/users/application-developer/foundational.md b/content/en/docs/user-journeys/users/application-developer/foundational.md deleted file mode 100644 index 43226f1bad..0000000000 --- a/content/en/docs/user-journeys/users/application-developer/foundational.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -reviewers: -- chenopis -layout: docsportal -css: /css/style_user_journeys.css -js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js -title: Foundational -track: "USERS â€ș APPLICATION DEVELOPER â€ș FOUNDATIONAL" -content_template: templates/user-journey-content ---- - -{{% capture overview %}} -If you're a developer looking to run applications on Kubernetes, this page and its linked topics can help you get started with the fundamentals. Though this page primarily describes development workflows, {{< link text="the subsequent page in the series" url="/docs/home/?path=users&persona=app-developer&level=intermediate" >}} covers more advanced, production setups. - -{{< note >}} -**A quick note**
This app developer "user journey" is *not* a comprehensive overview of Kubernetes. It focuses more on *what* you develop, test, and deploy to Kubernetes, rather than *how* the underlying infrastructure works.

Though it's possible for a single person to manage both, in many organizations, it’s common to assign the latter to a dedicated {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}. -{{< /note >}} -{{% /capture %}} - - -{{% capture body %}} -## Get started with a cluster - -#### Web-based environment - -If you're brand new to Kubernetes and simply want to experiment without setting up a full development environment, *web-based environments* are a good place to start: - -* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/#basics-modules" >}} - Introduces you to six common Kubernetes workflows. Each section walks you through browser-based, interactive exercises complete with their own Kubernetes environment. - -* {{< link text="Katacoda" url="https://www.katacoda.com/courses/kubernetes/playground" >}} - The playground equivalent of the environment used in *Kubernetes Basics* above. Katacoda also provides {{< link text="more advanced tutorials" url="https://www.katacoda.com/courses/kubernetes/" >}}, such as "Liveness and Readiness Healthchecks". - - -* {{< link text="Play with Kubernetes" url="http://labs.play-with-k8s.com/" >}} - A less structured environment than the *Katacoda* playground, for those who are more comfortable with Kubernetes concepts and want to explore further. It supports the ability to spin up multiple nodes. - - -#### Minikube (recommended) - -Web-based environments are easy to access, but are not persistent. If you want to continue exploring Kubernetes in a workspace that you can come back to and change, *Minikube* is a good option. - -Minikube can be installed locally, and runs a simple, single-node Kubernetes cluster inside a virtual machine (VM). This cluster is fully functioning and contains all core Kubernetes components. Many developers have found this sufficient for local application development. - -* {{< link text="Install Minikube" url="/docs/tasks/tools/install-minikube/" >}}. - -* {{< link text="Install kubectl" url="/docs/tasks/tools/install-kubectl/" >}}. ({{< glossary_tooltip text="What is kubectl?" term_id="kubectl" >}}) - -* *(Optional)* {{< link text="Install Docker" url="/docs/setup/production-environment/container-runtimes/#docker" >}} if you plan to run your Minikube cluster as part of a local development environment. - - Minikube includes a Docker daemon, but if you're developing applications locally, you'll want an independent Docker instance to support your workflow. This allows you to create {{< glossary_tooltip text="containers" term_id="container" >}} and push them to a container registry. - - {{< note >}} - Version 1.12 is recommended for full compatibility with Kubernetes, but a few other versions are tested and known to work. - {{< /note >}} - -You can get basic information about your cluster with the commands `kubectl cluster-info` and `kubectl get nodes`. However, to get a good idea of what's really going on, you need to deploy an application to your cluster. This is covered in the next section. - -#### MicroK8s - -On Linux, *MicroK8s* is a good alternative to Minikube for a local -install of Kubernetes: - -* Runs on the native OS, so there is no overhead from running a virtual machine. -* Always provides the latest stable version of Kubernetes, using built-in auto-upgrade functionality. -* Installs in less than a minute. - -* {{< link text="Install microk8s" url="https://microk8s.io/" >}}. - -After you install MicroK8s, you can use its tab-completion -functionality. All MicroK8s commands start with `microk8s.`. Type -`microk8s.` (with the period) and then use the tab key to see a list -of available commands. - -It also includes commands to enable Kubernetes subsystems. For example: - -* the Kubernetes Dashboard -* the DNS service -* GPU passthrough (for NVIDIA) -* Ingress -* Istio -* Metrics server -* Registry -* Storage - -## Deploy an application - -#### Basic workloads - -The following examples demonstrate the fundamentals of deploying Kubernetes apps: - - * **Stateless apps**: {{< link text="Deploy a simple nginx server" url="/docs/tasks/run-application/run-stateless-application-deployment/" >}}. - - * **Stateful apps**: {{< link text="Deploy a MySQL database" url="/docs/tasks/run-application/run-single-instance-stateful-application/" >}}. - -Through these deployment tasks, you'll gain familiarity with the following: - -* General concepts - - * **Configuration files** - Written in YAML or JSON, these files describe the desired state of your application in terms of Kubernetes API objects. A file can include one or more API object descriptions (*manifests*). (See [the example YAML](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment) from the stateless app). - - * **{{< glossary_tooltip text="Pods" term_id="pod" >}}** - This is the basic unit for all of the workloads you run on Kubernetes. These workloads, such as *Deployments* and *Jobs*, are composed of one or more Pods. To learn more, check out {{< link text="this explanation of Pods and Nodes" url="/docs/tutorials/kubernetes-basics/explore-intro/" >}}. - -* Common workload objects - * **{{< glossary_tooltip text="Deployment" term_id="deployment" >}}** - The most common way of running *X* copies (Pods) of your application. Supports rolling updates to your container images. - - * **{{< glossary_tooltip text="Service" term_id="service" >}}** - By itself, a Deployment can't receive traffic. Setting up a Service is one of the simplest ways to configure a Deployment to receive and loadbalance requests. Depending on the `type` of Service used, these requests can come from external client apps or be limited to apps within the same cluster. A Service is tied to a specific Deployment using {{< glossary_tooltip text="label" term_id="label" >}} selection. - -The subsequent topics are also useful to know for basic application deployment. - -#### Metadata - -You can also specify custom information about your Kubernetes API objects by attaching key/value fields. Kubernetes provides two ways of doing this: - -* **{{< glossary_tooltip text="Labels" term_id="label" >}}** - Identifying metadata that you can use to sort and select sets of API objects. Labels have many applications, including the following: - - * *To keep the right number of replicas (Pods) running in a Deployment.* The specified label (`app: nginx` in the {{< link text="stateless app example" url="/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment" >}}) is used to stamp the Deployment's newly created Pods (as the value of the `spec.template.labels` configuration field), and to query which Pods it already manages (as the value of `spec.selector.matchLabels`). - - * *To tie a Service to a Deployment* using the `selector` field, which is demonstrated in the {{< link text="stateful app example" url="/docs/tasks/run-application/run-single-instance-stateful-application/#deploy-mysql" >}}. - - * *To look for specific subset of Kubernetes objects, when you are using {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.* For instance, the command `kubectl get deployments --selector=app=nginx` only displays Deployments from the nginx app. - -* **{{< glossary_tooltip text="Annotations" term_id="annotation" >}}** - Nonidentifying metadata that you can attach to API objects, usually if you don't intend to use them for sorting purposes. These often serve as supplementary data about an app's deployment, such as Git SHAs, PR numbers, or URL pointers to observability dashboards. - - -#### Storage - -You'll also want to think about storage. Kubernetes provides different types of storage API objects for different storage needs: - -* **{{< glossary_tooltip text="Volumes" term_id="volume" >}}** - Let you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn {{< link text="how to configure volume storage" url="/docs/tasks/configure-pod-container/configure-volume-storage/" >}}, or {{< link text="read more about volume storage" url="/docs/concepts/storage/volumes/" >}}. - -* **{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}** and **{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}}** - Let you define storage at the cluster level. Typically a cluster operator defines the PersistentVolume objects for the cluster, and cluster users (application developers, you) define the PersistentVolumeClaim objects that your application requires. Learn {{< link text="how to set up persistent storage for your cluster" url="/docs/tasks/configure-pod-container/configure-persistent-volume-storage/" >}} or {{< link text="read more about persistent volumes" url="/docs/concepts/storage/persistent-volumes/" >}}. - -#### Configuration - -To avoid having to unnecessarily rebuild your container images, you should decouple your application's *configuration data* from the code required to run it. There are a couple ways of doing this, which you should choose according to your use case: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ApproachType of DataHow it's mountedExample
Using a manifest's container definitionNon-confidentialEnvironment variableCommand-line flag
Using {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}Non-confidentialEnvironment variable OR local filenginx configuration
Using {{< glossary_tooltip text="Secrets" term_id="secret" >}}ConfidentialEnvironment variable OR local fileDatabase credentials
- -{{< note >}} -If you have any data that you want to keep private, you should be using a Secret. Otherwise there is nothing stopping that data from being exposed to malicious users. -{{< /note >}} - -## Understand basic Kubernetes architecture - -As an app developer, you don't need to know everything about the inner workings of Kubernetes, but you may find it helpful to understand it at a high level. - -#### What Kubernetes offers - -Say that your team is deploying an ordinary Rails application. You've run some calculations and determined that you need five instances of your app running at any given time, in order to handle external traffic. - -If you're not running Kubernetes or a similar automated system, you might find the following scenario familiar: - -{{< note >}} -1. One instance of your app (a complete machine instance or just a container) goes down. - -1. Because your team has monitoring set up, this pages the person on call. - -1. The on-call person has to go in, investigate, and manually spin up a new instance. - -1. Depending how your team handles DNS/networking, the on-call person may also need to also update the service discovery mechanism to point at the IP of the new Rails instance rather than the old. -{{< /note >}} - -This process can be tedious and also inconvenient, especially if (2) happens in the early hours of the morning! - -**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes {{< link text="control plane" url="/docs/concepts/overview/components/#master-components" >}}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a result, Kubernetes is often referred to as a *self-healing* system. - -There are two key parts of the control plane that facilitate this behavior: the *Kubernetes API server* and the *Controllers*. - -#### Kubernetes API server - -For Kubernetes to be useful, it needs to know *what* sort of cluster state you want it to maintain. Your YAML or JSON *configuration files* declare this desired state in terms of one or more API objects, such as {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. To make updates to your cluster's state, you submit these files to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server (`kube-apiserver`). - -Examples of state include but are not limited to the following: - -* The applications or other workloads to run -* The container images for your applications and workloads -* Allocation of network and disk resources - -Note that the API server is just the gateway, and that object data is actually stored in a highly available datastore called {{< link text="*etcd*" url="https://github.com/coreos/etcd" >}}. For most intents and purposes, though, you can focus on the API server. Most reads and writes to cluster state take place as API requests. - -For more information, see {{< link text="Understanding Kubernetes Objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}. - -#### Controllers - -Once you’ve declared your desired state through the Kubernetes API, the *controllers* work to make the cluster’s current state match this desired state. - -The standard controller processes are {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}} and {{< link text="`cloud-controller-manager`" url="/docs/concepts/overview/components/#cloud-controller-manager" >}}, but you can also write your own controllers as well. - -All of these controllers implement a *control loop*. For simplicity, you can think of this as the following: - -{{< note >}} -1. What is the current state of the cluster (X)? - -1. What is the desired state of the cluster (Y)? - -1. X == Y ? - - * `true` - Do nothing. - * `false` - Perform tasks to get to Y, such as starting or restarting containers, - or scaling the number of replicas of a given application. Return to 1. -{{< /note >}} - -By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="/docs/concepts/" >}}. - -## Additional resources - -The Kubernetes documentation is rich in detail. Here's a curated list of resources to help you start digging deeper. - -### Basic concepts - -* {{< link text="More about the components that run Kubernetes" url="/docs/concepts/overview/components/" >}} - -* {{< link text="Understanding Kubernetes objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}} - -* {{< link text="More about Node objects" url="/docs/concepts/architecture/nodes/" >}} - -* {{< link text="More about Pod objects" url="/docs/concepts/workloads/pods/pod-overview/" >}} - -### Tutorials - -* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/" >}} - -* {{< link text="Hello Minikube" url="/docs/tutorials/stateless-application/hello-minikube/" >}} *(Runs on Mac only)* - -* {{< link text="Kubernetes object management" url="/docs/tutorials/object-management-kubectl/object-management/" >}} - -### What's next - -If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys: - -* {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} - Dive deeper, with the next level of this journey. -* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys. - -{{% /capture %}} diff --git a/content/en/docs/user-journeys/users/application-developer/intermediate.md b/content/en/docs/user-journeys/users/application-developer/intermediate.md deleted file mode 100644 index 1a3915f224..0000000000 --- a/content/en/docs/user-journeys/users/application-developer/intermediate.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -reviewers: -- chenopis -layout: docsportal -css: /css/style_user_journeys.css -js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js -title: Intermediate -track: "USERS â€ș APPLICATION DEVELOPER â€ș INTERMEDIATE" -content_template: templates/user-journey-content ---- - - -{{% capture overview %}} - -{{< note >}} - This page assumes that you've experimented with Kubernetes before. At this point, you should have basic experience interacting with a Kubernetes cluster (locally with Minikube, or elsewhere), and using API objects like Deployments to run your applications.

If not, you should review the {{< link text="Beginner App Developer" url="/docs/user-journeys/users/application-developer/foundational/" >}} topics first. -{{< /note >}} -After checking out the current page and its linked sections, you should have a better understanding of the following: - -* Additional Kubernetes workload patterns, beyond Deployments -* What it takes to make a Kubernetes application production-ready -* Community tools that can improve your development workflow - -{{% /capture %}} - - -{{% capture body %}} - -## Learn additional workload patterns - -As your Kubernetes use cases become more complex, you may find it helpful to familiarize yourself with more of the toolkit that Kubernetes provides. {{< link text="Basic workload" url="/docs/user-journeys/users/application-developer/foundational/#section-2" >}} objects like {{< glossary_tooltip text="Deployments" term_id="deployment" >}} make it straightforward to run, update, and scale applications, but they are not ideal for every scenario. - -The following API objects provide functionality for additional workload types, whether they are *persistent* or *terminating*. - -#### Persistent workloads - -Like Deployments, these API objects run indefinitely on a cluster until they are manually terminated. They are best for long-running applications. - -* **{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}** - Like Deployments, StatefulSets allow you to specify that a - certain number of replicas should be running for your application. - - {{< note >}} It's misleading to say that Deployments can't handle stateful workloads. Using {{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}, you can persist data beyond the lifecycle of any individual Pod in your Deployment. - {{< /note >}} - - However, StatefulSets can provide stronger guarantees about "recovery" behavior than Deployments. StatefulSets maintain a sticky, stable identity for their Pods. The following table provides some concrete examples of what this might look like: - - | | Deployment | StatefulSet | - |---|---|---| - | **Example Pod name** | `example-b1c4` | `example-0` | - | **When a Pod dies** | Reschedule on *any* node, with new name `example-a51z` | Reschedule on same node, as `example-0` | - | **When a node becomes unreachable** | Pod(s) are scheduled onto new node, with new names | Pod(s) are marked as "Unknown", and aren't rescheduled unless the Node object is forcefully deleted | - - In practice, this means that StatefulSets are best suited for scenarios where replicas (Pods) need to coordinate their workloads in a strongly consistent manner. Guaranteeing an identity for each Pod helps avoid {{< link text="split-brain" url="https://en.wikipedia.org/wiki/Split-brain_(computing)" >}} side effects in the case when a node becomes unreachable ({{< link text="network partition" url="https://en.wikipedia.org/wiki/Network_partition" >}}). This makes StatefulSets a great fit for distributed datastores like Cassandra or Elasticsearch. - - -* **{{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}** - DaemonSets run continuously on every node in your cluster, even as nodes are added or swapped in. This guarantee is particularly useful for setting up global behavior across your cluster, such as: - - * Logging and monitoring, from applications like `fluentd` - * Network proxy or {{< link text="service mesh" url="https://www.linux.com/news/whats-service-mesh-and-why-do-i-need-one" >}} - - -#### Terminating workloads - -In contrast to Deployments, these API objects are finite. They stop once the specified number of Pods have completed successfully. - -* **{{< glossary_tooltip text="Jobs" term_id="job" >}}** - You can use these for one-off tasks like running a script or setting up a work queue. These tasks can be executed sequentially or in parallel. These tasks should be relatively independent, as Jobs do not support closely communicating parallel processes. {{< link text="Read more about Job patterns" url="/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-patterns" >}}. - -* **{{< glossary_tooltip text="CronJobs" term_id="cronjob" >}}** - These are similar to Jobs, but allow you to schedule their execution for a specific time or for periodic recurrence. You might use CronJobs to send reminder emails or to run backup jobs. They are set up with a similar syntax as *crontab*. - -#### Other resources - -For more info, you can check out {{< link text="a list of additional Kubernetes resource types" url="/docs/reference/kubectl/overview/#resource-types" >}} as well as the {{< link text="API reference docs" url="{{ reference_docs_url }}" >}}. - -There may be additional features not mentioned here that you may find useful, which are covered in the {{< link text="full Kubernetes documentation" url="/docs/home/?path=browse" >}}. - -## Deploy a production-ready workload - -The beginner tutorials on this site, such as the {{< link text="Guestbook app" url="/docs/tutorials/stateless-application/guestbook/" >}}, are geared towards getting workloads up and running on your cluster. This prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you need to follow some additional best practices. - -#### Declarative configuration - -You are likely interacting with your Kubernetes cluster via {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. kubectl can be used to debug the current state of your cluster (such as checking the number of nodes), or to modify live Kubernetes objects (such as updating a workload's replica count with `kubectl scale`). - -When using kubectl to update your Kubernetes objects, it's important to be aware that different commands correspond to different approaches: - -* {{< link text="Purely imperative" url="/docs/tutorials/object-management-kubectl/imperative-object-management-command/" >}} -* {{< link text="Imperative with local configuration files" url="/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/" >}} (typically YAML) -* {{< link text="Declarative with local configuration files" url="/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/" >}} (typically YAML) - -There are pros and cons to each approach, though the declarative approach (such as `kubectl apply -f`) may be most helpful in production. With this approach, you rely on local YAML files as the source of truth about your desired state. This enables you to version control your configuration, which is helpful for code reviews and audit tracking. - -For additional configuration best practices, familiarize yourself with {{< link text="this guide" url="/docs/concepts/configuration/overview/" >}}. - -#### Security - -You may be familiar with the *principle of least privilege*---if you are too generous with permissions when writing or using software, the negative effects of a compromise can escalate out of control. Would you be cautious handing out `sudo` privileges to software on your OS? If so, you should be just as careful when granting your workload permissions to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server! The API server is the gateway for your cluster's source of truth; it provides endpoints to read or modify cluster state. - -You (or your {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}) can lock down API access with the following: - -* **{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}** - An "identity" that your Pods can be tied to -* **{{< glossary_tooltip text="RBAC" term_id="rbac" >}}** - One way of granting your ServiceAccount explicit permissions - -For even more comprehensive reading about security best practices, consider checking out the following topics: - -* {{< link text="Authentication" url="/docs/reference/access-authn-authz/authentication/" >}} (Is the user who they say they are?) -* {{< link text="Authorization" url="/docs/admin/authorization/" >}} (Does the user actually have permissions to do what they're asking?) - -#### Resource isolation and management - -If your workloads are operating in a *multi-tenant* environment with multiple teams or projects, your container(s) are not necessarily running alone on their node(s). They are sharing node resources with other containers which you do not own. - -Even if your cluster operator is managing the cluster on your behalf, it is helpful to be aware of the following: - -* **{{< glossary_tooltip text="Namespaces" term_id="namespace" >}}**, used for isolation -* **{{< link text="Resource quotas" url="/docs/concepts/policy/resource-quotas/" >}}**, which affect what your team's workloads can use -* **{{< link text="Memory" url="/docs/tasks/configure-pod-container/assign-memory-resource/" >}} and {{< link text="CPU" url="/docs/tasks/configure-pod-container/assign-cpu-resource/" >}} requests**, for a given Pod or container -* **{{< link text="Monitoring" url="/docs/tasks/debug-application-cluster/resource-usage-monitoring/" >}}**, both on the cluster level and the app level - -This list may not be completely comprehensive, but many teams have existing processes that take care of all this. If this is not the case, you'll find the Kubernetes documentation fairly rich in detail. - -## Improve your dev workflow with tooling - -As an app developer, you'll likely encounter the following tools in your workflow. - -#### kubectl - -`kubectl` is a command-line tool that allows you to easily read or modify your Kubernetes cluster. It provides convenient, short commands for common operations like scaling app instances and getting node info. How does kubectl do this? It's basically just a user-friendly wrapper for making API requests. It's written using {{< link text="client-go" url="https://github.com/kubernetes/client-go/#client-go" >}}, the Go library for the Kubernetes API. - -To learn about the most commonly used kubectl commands, check out the {{< link text="kubectl cheatsheet" url="/docs/reference/kubectl/cheatsheet/" >}}. It explains topics such as the following: - -* {{< link text="kubeconfig files" url="/docs/tasks/access-application-cluster/configure-access-multiple-clusters/" >}} - Your kubeconfig file tells kubectl what cluster to talk to, and can reference multiple clusters (such as dev and prod). -* {{< link text="The various output formats available" url="/docs/reference/kubectl/cheatsheet/#formatting-output" >}} - This is useful to know when you are using `kubectl get` to list information about certain API objects. - -* {{< link text="The JSONPath output format" url="/docs/reference/kubectl/jsonpath/" >}} - This is related to the output formats above. JSONPath is especially useful for parsing specific subfields out of `kubectl get` output (such as the URL of a {{< glossary_tooltip text="Service" term_id="service" >}}). - -* {{< link text="`kubectl run` vs `kubectl apply`" url="/docs/reference/kubectl/conventions/" >}} - This ties into the [declarative configuration](#declarative-configuration) discussion in the previous section. - -For the full list of kubectl commands and their options, check out {{< link text="the reference guide" url="/docs/reference/generated/kubectl/kubectl-commands" >}}. - -#### Helm - -To leverage pre-packaged configurations from the community, you can use **{{< glossary_tooltip text="Helm charts" term_id="helm-chart" >}}**. - -Helm charts package up YAML configurations for specific apps like Jenkins and Postgres. You can then install and run these apps on your cluster with minimal extra configuration. This approach makes the most sense for "off-the-shelf" components which do not require much custom implementation logic. - -For writing your own Kubernetes app configurations, there is a {{< link text="thriving ecosystem of tools" url="https://docs.google.com/a/heptio.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit?usp=drive_web" >}} that you may find useful. - -## Explore additional resources - -#### References -Now that you're fairly familiar with Kubernetes, you may find it useful to browse the following reference pages. Doing so provides a high level view of what other features may exist: - -* {{< link text="Commonly used `kubectl` commands" url="/docs/reference/kubectl/cheatsheet/" >}} -* {{< link text="Kubernetes API reference" url="{{ reference_docs_url }}" >}} -* {{< link text="Standardized Glossary" url="/docs/reference/glossary/" >}} - -In addition, {{< link text="the Kubernetes Blog" url="https://kubernetes.io/blog/" >}} often has helpful posts on Kubernetes design patterns and case studies. - -#### What's next -If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys: - -* {{< link text="Advanced App Developer" url="/docs/user-journeys/users/application-developer/advanced/" >}} - Dive deeper, with the next level of this journey. -* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys. -{{% /capture %}} - - diff --git a/content/en/docs/user-journeys/users/cluster-operator/foundational.md b/content/en/docs/user-journeys/users/cluster-operator/foundational.md deleted file mode 100644 index e74b7c5964..0000000000 --- a/content/en/docs/user-journeys/users/cluster-operator/foundational.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -reviewers: -- chenopis -layout: docsportal -css: /css/style_user_journeys.css -js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js -title: Foundational -track: "USERS â€ș CLUSTER OPERATOR â€ș FOUNDATIONAL" -content_template: templates/user-journey-content ---- - -{{% capture overview %}} - -If you want to learn how to get started managing and operating a Kubernetes cluster, this page and the linked topics introduce you to the foundational concepts and tasks. -This page introduces you to a Kubernetes cluster and key concepts to understand and manage it. The content focuses primarily on the cluster itself rather than the software running within the cluster. - -{{% /capture %}} - - - -{{% capture body %}} - -## Get an overview of Kubernetes - -If you have not already done so, start your understanding by reading through [What is Kubernetes?](/docs/concepts/overview/what-is-kubernetes/), which introduces a number of basic concepts and terms. - -Kubernetes is quite flexible, and a cluster can be run in a wide variety of places. You can interact with Kubernetes entirely on your own laptop or local development machine with it running within a virtual machine. Kubernetes can also run on virtual machines hosted either locally or in a cloud provider, and you can run a Kubernetes cluster on bare metal. - -A cluster is made up of one or more [Nodes](/docs/concepts/architecture/nodes/); where a node is a physical or virtual machine. -If there is more than one node in your cluster then the nodes are connected with a [cluster network](/docs/concepts/cluster-administration/networking/). -Regardless of how many nodes, all Kubernetes clusters generally have the same components, which are described in [Kubernetes Components](/docs/concepts/overview/components). - - -## Learn about Kubernetes basics - -A good way to become familiar with how to manage and operate a Kubernetes cluster is by setting one up. -One of the most compact ways to experiment with a cluster is [Installing and using Minikube](/docs/tasks/tools/install-minikube/). -Minikube is a command line tool for setting up and running a single-node cluster within a virtual machine on your local laptop or development computer. Minikube is even available through your browser at the [Katacoda Kubernetes Playground](https://www.katacoda.com/courses/kubernetes/playground). -Katacoda provides a browser-based connection to a single-node cluster, using minikube behind the scenes, to support a number of tutorials to explore Kubernetes. You can also leverage the web-based [Play with Kubernetes](http://labs.play-with-k8s.com/) to the same ends - a temporary cluster to play with on the web. - -You interact with Kubernetes either through a dashboard, an API, or using a command-line tool (such as `kubectl`) that interacts with the Kubernetes API. -Be familiar with [Organizing Cluster Access](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) by using configuration files. -The Kubernetes API exposes a number of resources that provide the building blocks and abstractions that are used to run software on Kubernetes. -Learn more about these resources at [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects). -These resources are covered in a number of articles within the Kubernetes documentation. - -* [Pod Overview](/docs/concepts/workloads/pods/pod-overview/) - * [Pods](/docs/concepts/workloads/pods/pod/) - * [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) - * [Deployments](/docs/concepts/workloads/controllers/deployment/) - * [Garbage Collection](/docs/concepts/workloads/controllers/garbage-collection/) - * [Container Images](/docs/concepts/containers/images/) - * [Container Environment Variables](/docs/concepts/containers/container-environment-variables/) -* [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/) -* [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) - * [Namespaces Walkthrough](/docs/tasks/administer-cluster/namespaces-walkthrough/) -* [Services](/docs/concepts/services-networking/service/) -* [Annotations](/docs/concepts/overview/working-with-objects/annotations/) -* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) -* [Secrets](/docs/concepts/configuration/secret/) - -As a cluster operator you may not need to use all these resources, although you should be familiar with them to understand how the cluster is being used. -There are a number of additional resources that you should be aware of, some listed under [Intermediate Resources](/docs/user-journeys/users/cluster-operator/intermediate#section-1). -You should also be familiar with [how to manage kubernetes resources](/docs/concepts/cluster-administration/manage-deployment/) -and [supported versions and version skew between cluster components](/docs/setup/release/version-skew-policy/). - -## Get information about your cluster - -You can [access clusters using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/). -If you are not already familiar with how to do this, you can review the [introductory tutorial](/docs/tutorials/kubernetes-basics/explore-intro/). -Using `kubectl`, you can retrieve information about your Kubernetes cluster very quickly. -To get basic information about the nodes in your cluster run the command `kubectl get nodes`. -You can get more detailed information for the same nodes with the command `kubectl describe nodes`. -You can see the status of the core of kubernetes with the command `kubectl get componentstatuses`. - -Some additional resources for getting information about your cluster and how it is operating include: - -* [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -* [Resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) - * [Metrics](/docs/concepts/cluster-administration/controller-metrics/) - -## Explore additional resources - -### Tutorials - -* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) -* [Configuring Redis with a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) -* Stateless Applications - * [Deploying PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook/) - * [Expose an External IP address to access an application](/docs/tutorials/stateless-application/expose-external-ip-address/) - -{{% /capture %}} diff --git a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md deleted file mode 100644 index b590e4862c..0000000000 --- a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -reviewers: -- chenopis -layout: docsportal -css: /css/style_user_journeys.css -js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js -title: Intermediate -track: "USERS > CLUSTER OPERATOR > INTERMEDIATE" -content_template: templates/user-journey-content ---- - -{{% capture overview %}} - -If you are a cluster operator looking to expand your grasp of Kubernetes, this page and its linked topics extend the information provided on the [foundational cluster operator page](/docs/user-journeys/users/cluster-operator/foundational). From this page you can get information on key Kubernetes tasks needed to manage a complete production cluster. - -{{% /capture %}} - -{{% capture body %}} - -## Work with ingress, networking, storage, and workloads - -Introductions to Kubernetes typically discuss simple stateless applications. As you move into more complex development, testing, and production environments, you need to consider more complex cases: - -Communication: Ingress and Networking - -* [Ingress](/docs/concepts/services-networking/ingress/) - -Storage: Volumes and PersistentVolumes - -* [Volumes](/docs/concepts/storage/volumes/) -* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/) - -Workloads - -* [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) -* [Stateful Sets](/docs/concepts/workloads/controllers/statefulset/) -* [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -* [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/) - -Pods - -* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) - * [Init Containers](/docs/concepts/workloads/pods/init-containers/) - * [Pod Presets](/docs/concepts/workloads/pods/podpreset/) - * [Container Lifecycle Hooks](/docs/concepts/containers/container-lifecycle-hooks/) - -And how Pods work with scheduling, priority, disruptions: - -* [Taints and Tolerations](/docs/concepts/configuration/taint-and-toleration/) -* [Pods and Priority](/docs/concepts/configuration/pod-priority-preemption/) -* [Disruptions](/docs/concepts/workloads/pods/disruptions/) -* [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/) -* [Managing Compute Resources for Containers](/docs/concepts/configuration/manage-compute-resources-container/) -* [Configuration Best Practices](/docs/concepts/configuration/overview/) - -## Implement security best practices - -Securing your cluster includes work beyond the scope of Kubernetes itself. - -In Kubernetes, you configure access control: - -* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) -* [Authenticating](/docs/reference/access-authn-authz/authentication/) -* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) - -You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases. - -* [Authorization Overview](/docs/reference/access-authn-authz/authorization/) -* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/) - -You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks). - - - -## Implement custom logging and monitoring - -Monitoring the health and state of your cluster is important. Collecting metrics, logging, and providing access to that information are common needs. Kubernetes provides some basic logging structure, and you may want to use additional tools to help aggregate and analyze log data. - -Start with the [basics on Kubernetes logging](/docs/concepts/cluster-administration/logging/) to understand how containers do logging and common patterns. Cluster operators often want to add something to gather and aggregate those logs. See the following topics: - -* [Logging Using Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/) -* [Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/) - -Like log aggregation, many clusters utilize additional software to help capture metrics and display them. There is an overview of tools at [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/). -Kubernetes also supports a [resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) which can be used by Horizontal Pod Autoscaler with custom metrics. - -[Prometheus](https://prometheus.io/), another {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project, is a common choice to support capture and temporary collection of metrics. There are several options for installing Prometheus, including using the [stable/prometheus](https://github.com/kubernetes/charts/tree/master/stable/prometheus) [helm](https://helm.sh/) chart, and CoreOS provides a [prometheus operator](https://github.com/coreos/prometheus-operator) and [kube-prometheus](https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus), which adds on Grafana dashboards and common configurations. - -A common configuration on [Minikube](https://github.com/kubernetes/minikube) and some Kubernetes clusters uses [Heapster](https://github.com/kubernetes/heapster) -[along with InfluxDB and Grafana](https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md). -There is a [walkthrough of how to install this configuration in your cluster](https://blog.kublr.com/how-to-utilize-the-heapster-influxdb-grafana-stack-in-kubernetes-for-monitoring-pods-4a553f4d36c9). -As of Kubernetes 1.11, Heapster is deprecated, as per [sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation). See [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/) for more information alternatives. - -Hosted monitoring, APM, or data analytics services such as [Datadog](https://docs.datadoghq.com/integrations/kubernetes/) or [Instana](https://www.instana.com/supported-integrations/kubernetes-monitoring/) also offer Kubernetes integration. - -## Additional resources - -Cluster Administration: - -* [Troubleshoot Clusters](/docs/tasks/debug-application-cluster/debug-cluster/) -* [Debug Pods and Replication Controllers](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) -* [Debug Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/) -* [Debug Stateful Sets](/docs/tasks/debug-application-cluster/debug-stateful-set/) -* [Debug Applications](/docs/tasks/debug-application-cluster/debug-application/) -* [Using explorer to investigate your cluster](https://github.com/kubernetes/examples/blob/master/staging/explorer/README.md) - -{{% /capture %}} - - diff --git a/content/en/examples/application/php-apache.yaml b/content/en/examples/application/php-apache.yaml new file mode 100644 index 0000000000..5eb04cfb89 --- /dev/null +++ b/content/en/examples/application/php-apache.yaml @@ -0,0 +1,39 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: php-apache +spec: + selector: + matchLabels: + run: php-apache + replicas: 1 + template: + metadata: + labels: + run: php-apache + spec: + containers: + - name: php-apache + image: k8s.gcr.io/hpa-example + ports: + - containerPort: 80 + resources: + limits: + cpu: 500m + requests: + cpu: 200m + +--- + +apiVersion: v1 +kind: Service +metadata: + name: php-apache + labels: + run: php-apache +spec: + ports: + - port: 80 + selector: + run: php-apache + diff --git a/content/en/examples/service/networking/network-policy-allow-all-egress.yaml b/content/en/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/en/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/en/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/en/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/en/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/en/examples/service/networking/network-policy-default-deny-all.yaml b/content/en/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..589f15eb3e --- /dev/null +++ b/content/en/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,9 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/en/examples/service/networking/network-policy-default-deny-egress.yaml b/content/en/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/en/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/en/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/en/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/en/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress diff --git a/content/fr/docs/concepts/configuration/secret.md b/content/fr/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..5c7ac8d1b2 --- /dev/null +++ b/content/fr/docs/concepts/configuration/secret.md @@ -0,0 +1,981 @@ +--- +title: Secrets +content_template: templates/concept +feature: + title: Gestion du secret et de la configuration + description: > + DĂ©ployez et mettez Ă  jour les secrets et la configuration des applications sans reconstruire votre image et sans dĂ©voiler les secrets de la configuration de vos applications. +weight: 50 +--- + + +{{% capture overview %}} + +Les objets `secret` de Kubernetes vous permettent de stocker et de gĂ©rer des informations sensibles, telles que les mots de passe, les jetons OAuth et les clĂ©s ssh. +Mettre ces informations dans un `secret` est plus sĂ»r et plus flexible que de le mettre en dur dans la dĂ©finition d'un {{< glossary_tooltip term_id="pod" >}} ou dans une {{< glossary_tooltip text="container image" term_id="image" >}}. +Voir [Document de conception des secrets](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) pour plus d'informations. + +{{% /capture %}} + +{{% capture body %}} + +## PrĂ©sentation des secrets + +Un secret est un objet qui contient une petite quantitĂ© de donnĂ©es sensibles telles qu'un mot de passe, un jeton ou une clĂ©. +De telles informations pourraient autrement ĂȘtre placĂ©es dans une spĂ©cification de pod ou dans une image; le placer dans un objet secret permet de mieux contrĂŽler la façon dont il est utilisĂ© et rĂ©duit le risque d'exposition accidentelle. + +Les utilisateurs peuvent crĂ©er des secrets et le systĂšme crĂ©e Ă©galement des secrets. + +Pour utiliser un secret, un pod doit rĂ©fĂ©rencer le secret. +Un secret peut ĂȘtre utilisĂ© avec un pod de deux maniĂšres: sous forme de fichiers dans un {{< glossary_tooltip text="volume" term_id="volume" >}} montĂ© sur un ou plusieurs de ses conteneurs, ou utilisĂ© par kubelet lorsque vous rĂ©cupĂ©rez des images pour le pod. + +### Secrets intĂ©grĂ©s + +#### Les comptes de service crĂ©ent et attachent automatiquement des secrets avec les informations d'identification de l'API + +Kubernetes crĂ©e automatiquement des secrets qui contiennent des informations d'identification pour accĂ©der Ă  l'API et il modifie automatiquement vos pods pour utiliser ce type de secret. + +La crĂ©ation et l'utilisation automatiques des informations d'identification de l'API peuvent ĂȘtre dĂ©sactivĂ©es ou remplacĂ©es si vous le souhaitez. +Cependant, si tout ce que vous avez Ă  faire est d'accĂ©der en toute sĂ©curitĂ© Ă  l'apiserver, il s'agit de la mĂ©thode recommandĂ©e. + +Voir la documentation des [Compte de service](/docs/tasks/configure-pod-container/configure-service-account/) pour plus d'informations sur le fonctionnement des comptes de service. + +### CrĂ©er vos propres secrets + +#### CrĂ©er un secret avec kubectl create secret + +Supposons que certains pods doivent accĂ©der Ă  une base de donnĂ©es. +Le nom d'utilisateur et le mot de passe que les pods doivent utiliser se trouvent dans les fichiers `./username.txt` et `./password.txt` sur votre machine locale. + +```shell +# Create files needed for rest of example. +echo -n 'admin' > ./username.txt +echo -n '1f2d1e2e67df' > ./password.txt +``` + +La commande `kubectl create secret` regroupe ces fichiers dans un secret et crĂ©e l'objet sur l'Apiserver. + +```shell +kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt +``` + +```text +secret "db-user-pass" created +``` + +{{< note >}} +Les caractĂšres spĂ©ciaux tels que `$`, `\`, `*`, et `!` seront interprĂ©tĂ©s par votre [shell](https://en.wikipedia.org/wiki/Shell_\(computing\)) et nĂ©cessitent d'ĂȘtre Ă©chappĂ©s. +Dans les shells les plus courants, le moyen le plus simple d'Ă©chapper au mot de passe est de l'entourer de guillemets simples (`'`). +Par exemple, si votre mot de passe rĂ©el est `S!B\*d$zDsb`, vous devez exĂ©cuter la commande de cette façon: + +```text +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb' +``` + +Vous n'avez pas besoin d'Ă©chapper les caractĂšres spĂ©ciaux dans les mots de passe des fichiers (`--from-file`). +{{< /note >}} + +Vous pouvez vĂ©rifier que le secret a Ă©tĂ© crĂ©Ă© comme ceci: + +```shell +kubectl get secrets +``` + +```text +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s +``` + +```text +kubectl describe secrets/db-user-pass +``` + +```text +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +{{< note >}} +`kubectl get` et `kubectl describe` Ă©vitent d'afficher le contenu d'un secret par dĂ©faut. +Il s'agit de protĂ©ger le secret contre une exposition accidentelle Ă  un spectateur de l'Ă©cran ou contre son stockage dans un journal de terminal. +{{< /note >}} + +Voir [dĂ©coder un secret](#decoding-a-secret) pour voir le contenu d'un secret. + +#### CrĂ©ation manuelle d'un secret + +Vous pouvez Ă©galement crĂ©er un secret dans un fichier d'abord, au format json ou yaml, puis crĂ©er cet objet. +Le [secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) contient deux table de hachage: `data` et `stringData`. +Le champ `data` est utilisĂ© pour stocker des donnĂ©es arbitraires, encodĂ©es en base64. +Le champ `stringData` est fourni pour plus de commoditĂ© et vous permet de fournir des donnĂ©es secrĂštes sous forme de chaĂźnes non codĂ©es. + +Par exemple, pour stocker deux chaĂźnes dans un secret Ă  l'aide du champ `data`, convertissez-les en base64 comme suit: + +```shell +echo -n 'admin' | base64 +YWRtaW4= +echo -n '1f2d1e2e67df' | base64 +MWYyZDFlMmU2N2Rm +``` + +Écrivez un secret qui ressemble Ă  ceci: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +Maintenant, crĂ©ez le secret en utilisant [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply): + +```text +kubectl apply -f ./secret.yaml +``` + +```text +secret "mysecret" created +``` + +Pour certains scĂ©narios, vous pouvez utiliser le champ `stringData` Ă  la place. +Ce champ vous permet de mettre une chaĂźne non codĂ©e en base64 directement dans le secret, et la chaĂźne sera codĂ©e pour vous lorsque le secret sera crĂ©Ă© ou mis Ă  jour. + +Un exemple pratique de cela pourrait ĂȘtre le suivant: vous dĂ©ployez une application qui utilise un secret pour stocker un fichier de configuration. +Vous souhaitez remplir des parties de ce fichier de configuration pendant votre processus de dĂ©ploiement. + +Si votre application utilise le fichier de configuration suivant: + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "user" +password: "password" +``` + +Vous pouvez stocker cela dans un secret en utilisant ce qui suit: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: |- + apiUrl: "https://my.api.com/api/v1" + username: {{username}} + password: {{password}} +``` + +Votre outil de dĂ©ploiement pourrait alors remplacer les variables de modĂšle `{{username}}` et `{{password}}` avant d'exĂ©cuter `kubectl apply`. + +`stringData` est un champ de commoditĂ© en Ă©criture seule. +Il n'est jamais affichĂ© lors de la rĂ©cupĂ©ration des secrets. +Par exemple, si vous exĂ©cutez la commande suivante: + +```text +kubectl get secret mysecret -o yaml +``` + +La sortie sera similaire Ă : + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +``` + +Si un champ est spĂ©cifiĂ© Ă  la fois dans `data` et `stringData`, la valeur de `stringData` est utilisĂ©e. +Par exemple, la dĂ©finition de secret suivante: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +Donnera le secret suivant: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +data: + username: YWRtaW5pc3RyYXRvcg== +``` + +OĂč `YWRtaW5pc3RyYXRvcg ==` dĂ©code en `administrateur`. + +Les clĂ©s de `data` et `stringData` doivent ĂȘtre composĂ©es de caractĂšres alphanumĂ©riques, '-', '_' ou '.'. + +**Encoding Note:** Les valeurs JSON et YAML sĂ©rialisĂ©es des donnĂ©es secrĂštes sont codĂ©es sous forme de chaĂźnes base64. +Les sauts de ligne ne sont pas valides dans ces chaĂźnes et doivent ĂȘtre omis. +Lors de l'utilisation de l'utilitaire `base64` sur Darwin / macOS, les utilisateurs doivent Ă©viter d'utiliser l'option `-b` pour diviser les longues lignes. +Inversement, les utilisateurs Linux *devraient* ajouter l'option `-w 0` aux commandes `base64` ou le pipeline `base64 | tr -d '\ n'` si l'option `-w` n'est pas disponible. + +#### CrĂ©ation d'un secret Ă  partir du gĂ©nĂ©rateur + +Kubectl prend en charge [la gestion des objets Ă  l'aide de Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) depuis 1.14. +Avec cette nouvelle fonctionnalitĂ©, vous pouvez Ă©galement crĂ©er un secret Ă  partir de gĂ©nĂ©rateurs, puis l'appliquer pour crĂ©er l'objet sur l'Apiserver. +Les gĂ©nĂ©rateurs doivent ĂȘtre spĂ©cifiĂ©s dans un `kustomization.yaml` Ă  l'intĂ©rieur d'un rĂ©pertoire. + +Par exemple, pour gĂ©nĂ©rer un secret Ă  partir des fichiers `./username.txt` et `./password.txt` + +```shell +# Create a kustomization.yaml file with SecretGenerator +cat <./kustomization.yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +EOF +``` + +Appliquez le rĂ©pertoire de personnalisation pour crĂ©er l'objet secret. + +```text +$ kubectl apply -k . +secret/db-user-pass-96mffmfh4k created +``` + +Vous pouvez vĂ©rifier que le secret a Ă©tĂ© crĂ©Ă© comme ceci: + +```text +$ kubectl get secrets +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s + +$ kubectl describe secrets/db-user-pass-96mffmfh4k +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +Par exemple, pour gĂ©nĂ©rer un secret Ă  partir des littĂ©raux `username=admin` et `password=secret`, vous pouvez spĂ©cifier le gĂ©nĂ©rateur de secret dans `kustomization.yaml` comme: + +```shell +# Create a kustomization.yaml file with SecretGenerator +$ cat <./kustomization.yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=secret +EOF +``` + +Appliquer le repertoire kustomization pour crĂ©er l'objet secret. + +```shell +$ kubectl apply -k . +secret/db-user-pass-dddghtt9b5 created +``` + +{{< note >}} +Le nom des secrets gĂ©nĂ©rĂ© a un suffixe ajoutĂ© en hachant le contenu. +Cela garantit qu'un nouveau secret est gĂ©nĂ©rĂ© chaque fois que le contenu est modifiĂ©. +{{< /note >}} + +#### DĂ©coder un secret + +Les secrets peuvent ĂȘtre rĂ©cupĂ©rĂ©s via la command `kubectl get secret`. +Par exemple, pour rĂ©cupĂ©rer le secret crĂ©Ă© dans la section prĂ©cĂ©dente: + +```shell +kubectl get secret mysecret -o yaml +``` + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +DĂ©codez le champ du mot de passe: + +```shell +echo 'MWYyZDFlMmU2N2Rm' | base64 --decode +``` + +```text +1f2d1e2e67df +``` + +#### Modification d'un secret + +Un secret existant peut ĂȘtre modifiĂ© avec la commande suivante: + +```text +kubectl edit secrets mysecret +``` + +Cela ouvrira l'Ă©diteur configurĂ© par dĂ©faut et permettra de mettre Ă  jour les valeurs secrĂštes codĂ©es en base64 dans le champ `data`: + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Utiliser les secrets + +Les secrets peuvent ĂȘtre montĂ©s en tant que volumes de donnĂ©es ou ĂȘtre exposĂ©s en tant que {{< glossary_tooltip text="variables d'environnement" term_id="container-env-variables" >}} Ă  utiliser par un conteneur dans un Pod. +Ils peuvent Ă©galement ĂȘtre utilisĂ©s par d'autres parties du systĂšme, sans ĂȘtre directement exposĂ©s aux Pods. +Par exemple, ils peuvent dĂ©tenir des informations d'identification que d'autres parties du systĂšme doivent utiliser pour interagir avec des systĂšmes externes en votre nom. + +### Utilisation de secrets comme fichiers d'un pod + +Pour consommer un secret dans un volume dans un pod: + +1. CrĂ©ez un secret ou utilisez-en un dĂ©jĂ  existant. + Plusieurs Pods peuvent rĂ©fĂ©rencer le mĂȘme secret. +1. Modifiez la dĂ©finition de votre Pod pour ajouter un volume sous `.spec.volumes[]`. + Nommez le volume et ayez un champ `.spec.volumes[].secret.secretName` Ă©gal au nom de l'objet secret. +1. Ajouter un `.spec.containers[].volumeMounts[]` Ă  chaque conteneur qui a besoin du secret. + SpĂ©cifier `.spec.containers[].volumeMounts[].readOnly = true` et `.spec.containers[].volumeMounts[].mountPath` Ă  un nom de rĂ©pertoire inutilisĂ© oĂč vous souhaitez que les secrets apparaissent. +1. Modifiez votre image et/ou votre ligne de commande pour que le programme recherche les fichiers dans ce rĂ©pertoire. + Chaque clĂ© de la carte secrĂšte `data` devient le nom de fichier sous `mountPath`. + +Voici un exemple de pod qui monte un secret dans un volume: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + +Chaque secret que vous souhaitez utiliser doit ĂȘtre mentionnĂ© dans `.spec.volumes`. + +S'il y a plusieurs conteneurs dans le pod, alors chaque conteneur a besoin de son propre bloc `volumeMounts`, mais un seul `.spec.volumes` est nĂ©cessaire par secret. + +Vous pouvez regrouper de nombreux fichiers en un seul secret ou utiliser de nombreux secrets, selon le cas. + +### Projection de clĂ©s secrĂštes vers des chemins spĂ©cifiques + +Nous pouvons Ă©galement contrĂŽler les chemins dans le volume oĂč les clĂ©s secrĂštes sont projetĂ©es. +Vous pouvez utiliser le champ `.spec.volumes []. Secret.items` pour changer le chemin cible de chaque clĂ©: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + +Que se passera-t-il: + +* `username` est stockĂ© dans le fichier `/etc/foo/my-group/my-username` au lieu de `/etc/foo/username`. +* `password` n'est pas projetĂ© + +Si `.spec.volumes[].secret.items` est utilisĂ©, seules les clĂ©s spĂ©cifiĂ©es dans `items` sont projetĂ©es. +Pour consommer toutes les clĂ©s du secret, toutes doivent ĂȘtre rĂ©pertoriĂ©es dans le champ `items`. +Toutes les clĂ©s rĂ©pertoriĂ©es doivent exister dans le secret correspondant. +Sinon, le volume n'est pas crĂ©Ă©. + +### Autorisations de fichiers secrets + +Vous pouvez Ă©galement spĂ©cifier les bits de mode d'autorisation des fichiers contenant les parties d'un secret. +Si vous n'en spĂ©cifiez pas, `0644` est utilisĂ© par dĂ©faut. +Vous pouvez spĂ©cifier un mode par dĂ©faut pour tout le volume secret et remplacer par clĂ© si nĂ©cessaire. + +Par exemple, vous pouvez spĂ©cifier un mode par dĂ©faut comme celui-ci: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 256 +``` + +Ensuite, le secret sera montĂ© sur `/etc/foo` et tous les fichiers crĂ©Ă©s par le montage de volume secret auront la permission `0400`. + +Notez que la spĂ©cification JSON ne prend pas en charge la notation octale, utilisez donc la valeur 256 pour les autorisations 0400. +Si vous utilisez yaml au lieu de json pour le pod, vous pouvez utiliser la notation octale pour spĂ©cifier les autorisations de maniĂšre plus naturelle. + +Vous pouvez aussi utiliser un mapping, comme dans l'exemple prĂ©cĂ©dent, et spĂ©cifier des autorisations diffĂ©rentes pour diffĂ©rents fichiers comme celui-ci: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 511 +``` + +Dans ce cas, le fichier rĂ©sultant `/etc/foo/my-group/my-username` aura la valeur d'autorisation de `0777`. +En raison des limitations JSON, vous devez spĂ©cifier le mode en notation dĂ©cimale. + +Notez que cette valeur d'autorisation peut ĂȘtre affichĂ©e en notation dĂ©cimale si vous la lisez plus tard. + +### Consommer des valeurs secrĂštes Ă  partir de volumes + +À l'intĂ©rieur du conteneur qui monte un volume secret, les clĂ©s secrĂštes apparaissent sous forme de fichiers et les valeurs secrĂštes sont dĂ©codĂ©es en base 64 et stockĂ©es Ă  l'intĂ©rieur de ces fichiers. +C'est le rĂ©sultat des commandes exĂ©cutĂ©es Ă  l'intĂ©rieur du conteneur de l'exemple ci-dessus: + +```shell +ls /etc/foo/ +``` + +```text +username +password +``` + +```shell +cat /etc/foo/username +``` + +```text +admin +``` + +```shell +cat /etc/foo/password +``` + +```text +1f2d1e2e67df +``` + +Le programme dans un conteneur est responsable de la lecture des secrets des fichiers. + +### Les secrets montĂ©s sont mis Ă  jour automatiquement + +Lorsqu'un secret dĂ©jĂ  consommĂ© dans un volume est mis Ă  jour, les clĂ©s projetĂ©es sont finalement mises Ă  jour Ă©galement. +Kubelet vĂ©rifie si le secret montĂ© est rĂ©cent Ă  chaque synchronisation pĂ©riodique. +Cependant, il utilise son cache local pour obtenir la valeur actuelle du Secret. +Le type de cache est configurable Ă  l'aide de le champ `ConfigMapAndSecretChangeDetectionStrategy` dans la structure [KubeletConfiguration](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). +Il peut ĂȘtre soit propagĂ© via watch (par dĂ©faut), basĂ© sur ttl, ou simplement redirigĂ© toutes les requĂȘtes vers directement kube-apiserver. +Par consĂ©quent, le dĂ©lai total entre le moment oĂč le secret est mis Ă  jour et le moment oĂč de nouvelles clĂ©s sont projetĂ©es sur le pod peut ĂȘtre aussi long que la pĂ©riode de synchronisation du kubelet + le dĂ©lai de propagation du cache, oĂč le dĂ©lai de propagation du cache dĂ©pend du type de cache choisi (cela Ă©quivaut au delai de propagation du watch, ttl du cache, ou bien zĂ©ro). + +{{< note >}} +Un conteneur utilisant un secret comme un volume [subPath](/docs/concepts/storage/volumes#using-subpath) montĂ© ne recevra pas de mises Ă  jour secrĂštes. +{{< /note >}} + +### Utilisation de secrets comme variables d'environnement + +Pour utiliser un secret dans une {{< glossary_tooltip text="variable d'environnement" term_id="container-env-variables" >}} dans un pod: + +1. CrĂ©ez un secret ou utilisez-en un dĂ©jĂ  existant. + Plusieurs pods peuvent rĂ©fĂ©rencer le mĂȘme secret. +1. Modifiez la dĂ©finition de votre pod dans chaque conteneur oĂč vous souhaitez utiliser la valeur d'une clĂ© secrĂšte pour ajouter une variable d'environnement pour chaque clĂ© secrĂšte que vous souhaitez consommer. + La variable d'environnement qui consomme la clĂ© secrĂšte doit remplir le nom et la clĂ© du secret dans `env[].valueFrom.secretKeyRef`. +1. Modifiez votre image et/ou votre ligne de commande pour que le programme recherche des valeurs dans les variables d'environnement spĂ©cifiĂ©es + +Voici un exemple de pod qui utilise des secrets de variables d'environnement: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +### Consommation de valeurs secrĂštes Ă  partir de variables d'environnement + +À l'intĂ©rieur d'un conteneur qui consomme un secret dans des variables d'environnement, les clĂ©s secrĂštes apparaissent comme des variables d'environnement normales contenant les valeurs dĂ©codĂ©es en base64 des donnĂ©es secrĂštes. +C'est le rĂ©sultat des commandes exĂ©cutĂ©es Ă  l'intĂ©rieur du conteneur de l'exemple ci-dessus: + +```shell +echo $SECRET_USERNAME +``` + +```text +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +```text +1f2d1e2e67df +``` + +### Utilisation des imagePullSecrets + +Un `imagePullSecret` est un moyen de transmettre un secret qui contient un mot de passe de registre d'images Docker (ou autre) au Kubelet afin qu'il puisse extraire une image privĂ©e au nom de votre Pod. + +#### SpĂ©cification manuelle d'une imagePullSecret + +L'utilisation de `imagePullSecrets` est dĂ©crite dans la [documentation des images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) + +### Arranging for imagePullSecrets to be Automatically Attached + +Vous pouvez crĂ©er manuellement un `imagePullSecret` et le rĂ©fĂ©rencer Ă  partir d'un `serviceAccount`. +Tous les pods crĂ©Ă©s avec ce `serviceAccount` ou cette valeur par dĂ©faut pour utiliser ce `serviceAccount`, verront leur champ `imagePullSecret` dĂ©fini sur celui du compte de service. +Voir [Ajouter ImagePullSecrets Ă  un compte de service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) pour une explication dĂ©taillĂ©e de ce processus. + +### Montage automatique de secrets crĂ©Ă©s manuellement + +Les secrets crĂ©Ă©s manuellement (par exemple, un contenant un jeton pour accĂ©der Ă  un compte github) peuvent ĂȘtre automatiquement associĂ©s aux pods en fonction de leur compte de service. +Voir [Injection d'informations dans des pods Ă  l'aide d'un PodPreset](/docs/tasks/inject-data-application/podpreset/) pour une explication dĂ©taillĂ©e de ce processus. + +## Details + +### Restrictions + +Les sources de volume secrĂštes sont validĂ©es pour garantir que la rĂ©fĂ©rence d'objet spĂ©cifiĂ©e pointe rĂ©ellement vers un objet de type Secret. +Par consĂ©quent, un secret doit ĂȘtre crĂ©Ă© avant tous les pods qui en dĂ©pendent. + +Les objets API secrets rĂ©sident dans un {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Ils ne peuvent ĂȘtre rĂ©fĂ©rencĂ©s que par des pods dans le mĂȘme espace de noms. + +Les secrets individuels sont limitĂ©s Ă  1 Mo de taille. +C'est pour dĂ©courager la crĂ©ation de trĂšs grands secrets qui Ă©puiseraient la mĂ©moire de l'apiserver et du kubelet. +Cependant, la crĂ©ation de nombreux petits secrets pourrait Ă©galement Ă©puiser la mĂ©moire. +Des limites plus complĂštes sur l'utilisation de la mĂ©moire en raison de secrets sont une fonctionnalitĂ© prĂ©vue. + +Kubelet prend uniquement en charge l'utilisation des secrets pour les pods qu'il obtient du serveur API. +Cela inclut tous les pods crĂ©Ă©s Ă  l'aide de kubectl, ou indirectement via un contrĂŽleur de rĂ©plication. +Il n'inclut pas les pods crĂ©Ă©s via les drapeaux kubelet `--manifest-url`, ou `--config`, ou son API REST (ce ne sont pas des moyens courants de crĂ©er des Pods). + +Les secrets doivent ĂȘtre crĂ©Ă©s avant d'ĂȘtre consommĂ©s dans les pods en tant que variables d'environnement, sauf s'ils sont marquĂ©s comme facultatifs. +Les rĂ©fĂ©rences Ă  des secrets qui n'existent pas empĂȘcheront le pod de dĂ©marrer. + +Les rĂ©fĂ©rences via `secretKeyRef` Ă  des clĂ©s qui n'existent pas dans un Secret nommĂ© empĂȘcheront le pod de dĂ©marrer. + +Les secrets utilisĂ©s pour remplir les variables d'environnement via `envFrom` qui ont des clĂ©s considĂ©rĂ©es comme des noms de variables d'environnement non valides verront ces clĂ©s ignorĂ©es. +Le pod sera autorisĂ© Ă  dĂ©marrer. +Il y aura un Ă©vĂ©nement dont la raison est `InvalidVariableNames` et le message contiendra la liste des clĂ©s invalides qui ont Ă©tĂ© ignorĂ©es. +L'exemple montre un pod qui fait rĂ©fĂ©rence au / mysecret par dĂ©faut qui contient 2 clĂ©s invalides, 1badkey et 2alsobad. + +```shell +kubectl get events +``` + +```text +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Cycle de vie de l'intĂ©raction Secret et Pod + +Lorsqu'un pod est crĂ©Ă© via l'API, il n'est pas vĂ©rifiĂ© s'il existe un secret rĂ©fĂ©rencĂ©. +Une fois qu'un pod est programmĂ©, le kubelet tentera de rĂ©cupĂ©rer la valeur secrĂšte. +Si le secret ne peut pas ĂȘtre rĂ©cupĂ©rĂ© parce qu'il n'existe pas ou en raison d'un manque temporaire de connexion au serveur API, kubelet rĂ©essayera pĂ©riodiquement. +Il rapportera un Ă©vĂ©nement sur le pod expliquant la raison pour laquelle il n'a pas encore dĂ©marrĂ©. +Une fois le secret rĂ©cupĂ©rĂ©, le kubelet crĂ©era et montera un volume le contenant. +Aucun des conteneurs du pod ne dĂ©marre tant que tous les volumes du pod ne sont pas montĂ©s. + +## Cas d'utilisation + +### Cas d'utilisation: pod avec clĂ©s SSH + +CrĂ©ez un kustomization.yaml avec un `SecretGenerator` contenant quelques clĂ©s SSH: + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + +```text +secret "ssh-key-secret" created +``` + +{{< caution >}} +RĂ©flĂ©chissez bien avant d'envoyer vos propres clĂ©s SSH: d'autres utilisateurs du cluster peuvent avoir accĂšs au secret. +Utilisez un compte de service que vous souhaitez rendre accessible Ă  tous les utilisateurs avec lesquels vous partagez le cluster Kubernetes et que vous pouvez rĂ©voquer s'ils sont compromis. +{{< /caution >}} + +Nous pouvons maintenant crĂ©er un pod qui rĂ©fĂ©rence le secret avec la clĂ© SSH et le consomme dans un volume: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +Lorsque la commande du conteneur s'exĂ©cute, les morceaux de la clĂ© seront disponibles dans: + +```shell +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + +Le conteneur est alors libre d'utiliser les donnĂ©es secrĂštes pour Ă©tablir une connexion SSH. + +### Cas d'utilisation: pods avec informations d'identification de prod/test + +Faites un fichier kustomization.yaml avec un SecretGenerator. + +Cet exemple illustre un Pod qui consomme un secret contenant des informations d'identification de prod et un autre Pod qui consomme un secret avec des informations d'identification d'environnement de test. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + +```text +secret "prod-db-secret" created +``` + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + +```text +secret "test-db-secret" created +``` + +{{< note >}} +CaractĂšres spĂ©ciaux tels que `$`, `\`, `*`, et `!` seront interprĂ©tĂ©s par votre [shell](https://en.wikipedia.org/wiki/Shell_\(computing\)) et nĂ©cessitent d'ĂȘtre Ă©chappĂ©s. +Dans les shells les plus courants, le moyen le plus simple d'Ă©chapper au mot de passe est de l'entourer de guillemets simples (`'`). +Par exemple, si votre mot de passe rĂ©el est `S!B\*d$zDsb`, vous devez exĂ©cuter la commande de cette façon: + +```text +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb' +``` + +Vous n'avez pas besoin d'Ă©chapper les caractĂšres spĂ©ciaux dans les mots de passe des fichiers (`--from-file`). +{{< /note >}} + +Maintenant, faites les pods: + +```shell +$ cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + +Ajoutez les pods Ă  la mĂȘme kustomization.yaml + +```shell +$ cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Appliquez tous ces objets sur l'Apiserver avec + +```shell +kubectl apply -k . +``` + +Les deux conteneurs auront les fichiers suivants prĂ©sents sur leurs systĂšmes de fichiers avec les valeurs pour l'environnement de chaque conteneur: + +```shell +/etc/secret-volume/username +/etc/secret-volume/password +``` + +Notez comment les spĂ©cifications pour les deux pods ne diffĂšrent que dans un champ; cela facilite la crĂ©ation de pods avec diffĂ©rentes capacitĂ©s Ă  partir d'un template de pod commun. + +Vous pouvez encore simplifier la spĂ©cification du pod de base en utilisant deux comptes de service: un appelĂ©, disons, `prod-user` avec le secret `prod-db-secret`, et un appelĂ©, `test-user` avec le secret `test-db-secret`. +Ensuite, la spĂ©cification du pod peut ĂȘtre raccourcie, par exemple: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### Cas d'utilisation: Dotfiles dans un volume secret + +Afin de masquer des donnĂ©es (c'est-Ă -dire dans un fichier dont le nom commence par un point), il suffit de faire commencer cette clĂ© par un point. +Par exemple, lorsque le secret suivant est montĂ© dans un volume: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +Le `secret-volume` contiendra un seul fichier, appelĂ© `.secret-file`, et le `dotfile-test-container` aura ce fichier prĂ©sent au chemin `/etc/secret-volume/.secret-file`. + +{{< note >}} +Les fichiers commençant par des points sont masquĂ©s de la sortie de `ls -l`; vous devez utiliser `ls -la` pour les voir lors de la liste du contenu du rĂ©pertoire. +{{< /note >}} + +### Cas d'utilisation: secret visible pour un conteneur dans un pod + +Envisagez un programme qui doit gĂ©rer les requĂȘtes HTTP, effectuer une logique mĂ©tier complexe, puis signer certains messages avec un HMAC. +Parce qu'il a une logique d'application complexe, il pourrait y avoir un exploit de lecture de fichier Ă  distance inaperçu dans le serveur, qui pourrait exposer la clĂ© privĂ©e Ă  un attaquant. + +Cela pourrait ĂȘtre divisĂ© en deux processus dans deux conteneurs: un conteneur frontal qui gĂšre l'interaction utilisateur et la logique mĂ©tier, mais qui ne peut pas voir la clĂ© privĂ©e; et un conteneur de signataire qui peut voir la clĂ© privĂ©e, et rĂ©pond aux demandes de signature simples du frontend (par exemple sur le rĂ©seau localhost). + +Avec cette approche partitionnĂ©e, un attaquant doit maintenant inciter le serveur d'applications Ă  faire quelque chose d'assez arbitraire, ce qui peut ĂȘtre plus difficile que de lui faire lire un fichier. + + + +## Les meilleures pratiques + +### Clients qui utilisent l'API secrets + +Lors du dĂ©ploiement d'applications qui interagissent avec l'API secrets, l'accĂšs doit ĂȘtre limitĂ© Ă  l'aide de [politiques d'autorisation](/docs/reference/access-authn-authz/authorization/) telles que [RBAC](/docs/reference/access-authn-authz/rbac/). + +Les secrets contiennent souvent des valeurs qui couvrent un spectre d'importance, dont beaucoup peuvent provoquer des escalades au sein de Kubernetes (par exemple, les jetons de compte de service) et vers les systĂšmes externes. +MĂȘme si une application individuelle peut raisonner sur la puissance des secrets avec lesquels elle s'attend Ă  interagir, d'autres applications dans le mĂȘme namespace peuvent rendre ces hypothĂšses invalides. + +Pour ces raisons, les requĂȘtes `watch` et `list` pour les secrets dans un namespace sont des capacitĂ©s extrĂȘmement puissantes et doivent ĂȘtre Ă©vitĂ©es, puisque la liste des secrets permet aux clients d'inspecter les valeurs de tous les secrets qui se trouvent dans ce namespace. +La capacitĂ© Ă  effectuer un `watch` ou `list` des secrets dans un cluster doit ĂȘtre rĂ©servĂ© uniquement aux composants les plus privilĂ©giĂ©s au niveau du systĂšme. + +Les applications qui ont besoin d'accĂ©der Ă  l'API secrets doivent effectuer des requĂȘtes `get` sur les secrets dont elles ont besoin. +Cela permet aux administrateurs de restreindre l'accĂšs Ă  tous les secrets tout en donnant [accĂšs en liste blanche aux instances individuelles](/docs/reference/access-authn-authz/rbac/#referring-to-resources) dont l'application a besoin. + +Pour des performances amĂ©liorĂ©es sur une boucle `get`, les clients peuvent concevoir des ressources qui font rĂ©fĂ©rence Ă  un secret puis `watch` la ressource, demandant Ă  nouveau le secret lorsque la ressource change. +De plus, un ["bulk watch" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) laisse les clients `watch` des ressources individuelles ont Ă©galement Ă©tĂ© proposĂ©es et seront probablement disponibles dans les prochaines versions de Kubernetes. + +## PropriĂ©tĂ©s de sĂ©curitĂ© + +### Protections + +Étant donnĂ© que les objets secrets peuvent ĂȘtre crĂ©Ă©s indĂ©pendamment des Pods qui les utilisent, il y a moins de risques que le secret soit exposĂ© pendant la crĂ©ation, la visualisation et la modification des Pods. +Le systĂšme peut Ă©galement prendre des prĂ©cautions supplĂ©mentaires avec les objets secrets, comme Ă©viter de les Ă©crire sur le disque lorsque cela est possible. + +Un secret n'est envoyĂ© Ă  un nƓud que si un module sur ce nƓud l'exige. +Kubelet stocke le secret dans un `tmpfs` afin que le secret ne soit pas Ă©crit sur le stockage sur disque. +Une fois que le pod qui dĂ©pend du secret est supprimĂ©, kubelet supprimera Ă©galement sa copie locale des donnĂ©es secrĂštes. + +Il peut y avoir des secrets pour plusieurs pods sur le mĂȘme nƓud. +Cependant, seuls les secrets qu'un pod demande sont potentiellement visibles dans ses conteneurs. +Par consĂ©quent, un pod n'a pas accĂšs aux secrets d'un autre pod. + +Il peut y avoir plusieurs conteneurs dans un pod. +Cependant, chaque conteneur d'un pod doit demander le volume secret dans ses `volumesMounts` pour qu'il soit visible dans le conteneur. +Cela peut ĂȘtre utilisĂ© pour construire des [partitions de sĂ©curitĂ© au niveau du pod](#use-case-secret-visible-to-one-container-in-a-pod). + +Sur la plupart des distributions gĂ©rĂ©es par le projet Kubernetes, la communication entre l'utilisateur vers l'apiserver et entre l'apiserver et les kubelets est protĂ©gĂ©e par SSL/TLS. +Les secrets sont protĂ©gĂ©s lorsqu'ils sont transmis sur ces canaux. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + +Vous pouvez activer le [chiffrement au repos](/docs/tasks/administer-cluster/encrypt-data/) pour les donnĂ©es secrĂštes, afin que les secrets ne soient pas stockĂ©s en clair dans {{< glossary_tooltip term_id="etcd" >}}. + +### Risques + +* Dans le serveur API, les donnĂ©es secrĂštes sont stockĂ©es dans {{< glossary_tooltip term_id="etcd" >}}; par consĂ©quent: + * Les administrateurs doivent activer le chiffrement au repos pour les donnĂ©es du cluster (nĂ©cessite la version 1.13 ou ultĂ©rieure) + * Les administrateurs devraient limiter l'accĂšs Ă  etcd aux utilisateurs administrateurs + * Les administrateurs peuvent vouloir effacer/dĂ©truire les disques utilisĂ©s par etcd lorsqu'ils ne sont plus utilisĂ©s + * Si vous exĂ©cutez etcd dans un cluster, les administrateurs doivent s'assurer d'utiliser SSL/TLS pour la communication peer-to-peer etcd. +* Si vous configurez le secret via un fichier manifeste (JSON ou YAML) qui a les donnĂ©es secrĂštes codĂ©es en base64, partager ce fichier ou l'archiver dans un dĂ©pot de source signifie que le secret est compromis. + L'encodage Base64 _n'est pas_ une mĂ©thode de chiffrement, il est considĂ©rĂ© comme identique au texte brut. +* Les applications doivent toujours protĂ©ger la valeur du secret aprĂšs l'avoir lu dans le volume, comme ne pas le mettre accidentellement dans un journal ou le transmettre Ă  une partie non fiable. +* Un utilisateur qui peut crĂ©er un pod qui utilise un secret peut Ă©galement voir la valeur de ce secret. + MĂȘme si la stratĂ©gie apiserver ne permet pas Ă  cet utilisateur de lire l'objet secret, l'utilisateur peut crĂ©er un pod qui expose le secret. +* Actuellement, toute personne disposant des droit root sur n'importe quel nƓud peut lire _n'importe quel_ secret depuis l'apiserver, en usurpant l'identitĂ© du kubelet. + Il est prĂ©vu de n'envoyer des secrets qu'aux nƓuds qui en ont rĂ©ellement besoin, pour limiter l'impact d'un exploit root sur un seul nƓud. + +{{% capture whatsnext %}} + +{{% /capture %}} diff --git a/content/fr/docs/concepts/storage/persistent-volumes.md b/content/fr/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000..e62c996ddb --- /dev/null +++ b/content/fr/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,756 @@ +--- +title: Volumes persistants +feature: + title: Orchestration du stockage + description: > + Montez automatiquement le systĂšme de stockage de votre choix, que ce soit Ă  partir du stockage local, d'un fournisseur de cloud public tel que GCP ou AWS, ou un systĂšme de stockage rĂ©seau tel que NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +Ce document dĂ©crit l'Ă©tat actuel de `PersistentVolumes` dans Kubernetes. +Une connaissance des [volumes](/fr/docs/concepts/storage/volumes/) est suggĂ©rĂ©e. + +{{% /capture %}} + +{{% capture body %}} + +## Introduction + +La gestion du stockage est un problĂšme distinct de la gestion des instances de calcul. +Le sous-systĂšme `PersistentVolume` fournit une API pour les utilisateurs et les administrateurs qui abstrait les dĂ©tails de la façon dont le stockage est fourni et de la façon dont il est utilisĂ©. +Pour ce faire, nous introduisons deux nouvelles ressources API: `PersistentVolume` et `PersistentVolumeClaim`. + +Un `PersistentVolume` (PV) est un Ă©lĂ©ment de stockage dans le cluster qui a Ă©tĂ© provisionnĂ© par un administrateur ou provisionnĂ© dynamiquement Ă  l'aide de [Storage Classes](/docs/concepts/storage/storage-classes/). +Il s'agit d'une ressource dans le cluster, tout comme un nƓud est une ressource de cluster. +Les PV sont des plugins de volume comme Volumes, mais ont un cycle de vie indĂ©pendant de tout pod individuel qui utilise le PV. +Cet objet API capture les dĂ©tails de l'implĂ©mentation du stockage, que ce soit NFS, iSCSI ou un systĂšme de stockage spĂ©cifique au fournisseur de cloud. + +Un `PersistentVolumeClaim` (PVC) est une demande de stockage par un utilisateur. +Il est similaire Ă  un Pod. +Les pods consomment des ressources de noeud et les PVC consomment des ressources PV. +Les pods peuvent demander des niveaux spĂ©cifiques de ressources (CPU et mĂ©moire). +Les PVC peuvent demander une taille et des modes d'accĂšs spĂ©cifiques (par exemple, ils peuvent ĂȘtre montĂ©s une fois en lecture/Ă©criture ou plusieurs fois en lecture seule). + +Alors que les `PersistentVolumeClaims` permettent Ă  un utilisateur de consommer des ressources de stockage abstraites, il est courant que les utilisateurs aient besoin de `PersistentVolumes` avec des propriĂ©tĂ©s et des performances variables pour diffĂ©rents problĂšmes. +Les administrateurs de cluster doivent ĂȘtre en mesure d'offrir une variĂ©tĂ© de `PersistentVolumes` qui diffĂšrent de bien des façons plus que la taille et les modes d'accĂšs, sans exposer les utilisateurs aux dĂ©tails de la façon dont ces volumes sont mis en Ɠuvre. +Pour ces besoins, il existe la ressource `StorageClass`. + +Voir la [procĂ©dure dĂ©taillĂ©e avec des exemples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Cycle de vie d'un PV et d'un PVC + +Les PV sont des ressources du cluster. +Les PVC sont des demandes pour ces ressources et agissent Ă©galement comme des contrĂŽles de rĂ©clamation pour la ressource. +L'interaction entre les PV et les PVC suit ce cycle de vie: + +### Provisionnement + +Les PV peuvent ĂȘtre provisionnĂ©s de deux maniĂšres: statiquement ou dynamiquement. + +#### Provisionnement statique + +Un administrateur de cluster crĂ©e un certain nombre de PV. +Ils contiennent les dĂ©tails du stockage rĂ©el, qui est disponible pour une utilisation par les utilisateurs du cluster. +Ils existent dans l'API Kubernetes et sont disponibles pour la consommation. + +#### Provisionnement dynamique + +Lorsqu'aucun des PV statiques crĂ©Ă©s par l'administrateur ne correspond au `PersistentVolumeClaim` d'un utilisateur, le cluster peut essayer de provisionner dynamiquement un volume spĂ©cialement pour le PVC. +Ce provisionnement est basĂ© sur les `StorageClasses`: le PVC doit demander une [storage class](/docs/concepts/storage/storage-classes/) et l'administrateur doit avoir crĂ©Ă© et configurĂ© cette classe pour que l'approvisionnement dynamique se produise. +Les PVC qui demandent la classe `""` dĂ©sactive le provisionnement dynamique pour eux-mĂȘmes. + +Pour activer le provisionnement de stockage dynamique basĂ© sur la classe de stockage, l'administrateur de cluster doit activer le `DefaultStorageClass` dans l'[contrĂŽleur d'admission](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) sur le serveur API. +Cela peut ĂȘtre fait, par exemple, en veillant Ă  ce que `DefaultStorageClass` figure parmi la liste de valeurs sĂ©parĂ©es par des virgules pour l'option `--enable-admission-plugins` du composant serveur API. +Pour plus d'informations sur les options de ligne de commande du serveur API, consultez la documentation [kube-apiserver](/docs/admin/kube-apiserver/). + +### Liaison + +Un utilisateur crĂ©e, ou dans le cas d'un provisionnement dynamique, a dĂ©jĂ  crĂ©Ă©, un `PersistentVolumeClaim` avec une quantitĂ© spĂ©cifique de stockage demandĂ©e et avec certains modes d'accĂšs. +Une boucle de contrĂŽle dans le maĂźtre surveille les nouveaux PVC, trouve un PV correspondant (si possible) et les lie ensemble. +Si un PV a Ă©tĂ© dynamiquement provisionnĂ© pour un nouveau PVC, la boucle liera toujours ce PV au PVC. +Sinon, l'utilisateur obtiendra toujours au moins ce qu'il a demandĂ©, mais le volume peut ĂȘtre supĂ©rieur Ă  ce qui a Ă©tĂ© demandĂ©. +Une fois liĂ©es, les liaisons `PersistentVolumeClaim` sont exclusives, quelle que soit la façon dont elles ont Ă©tĂ© liĂ©es. +Une liaison PVC-PV est une relation 1-Ă -1. + +Les PVC resteront non liĂ©s indĂ©finiment s'il n'existe pas de volume correspondant. +Le PVC sera liĂ© Ă  mesure que les volumes correspondants deviendront disponibles. +Par exemple, un cluster provisionnĂ© avec de nombreux PV 50Gi ne correspondrait pas Ă  un PVC demandant 100Gi. +Le PVC peut ĂȘtre liĂ© lorsqu'un PV 100Gi est ajoutĂ© au cluster. + +### Utilisation + +Les Pods utilisent les PVC comme des volumes. +Le cluster inspecte le PVC pour trouver le volume liĂ© et monte ce volume pour un Pod. +Pour les volumes qui prennent en charge plusieurs modes d'accĂšs, l'utilisateur spĂ©cifie le mode souhaitĂ© lors de l'utilisation de leur PVC comme volume dans un Pod. + +Une fois qu'un utilisateur a un PVC et que ce PVC est liĂ©, le PV liĂ© appartient Ă  l'utilisateur aussi longtemps qu'il en a besoin. +Les utilisateurs planifient des pods et accĂšdent Ă  leurs PV revendiquĂ©s en incluant un `persistentVolumeClaim` dans le bloc de volumes de leur Pod [Voir ci-dessous pour les dĂ©tails de la syntaxe](#claims-as-volumes). + +### Protection de l'objet de stockage en cours d'utilisation + +Le but de la fonction de protection des objets de stockage utilisĂ©s est de garantir que les revendications de volume persistantes (PVC) en cours d'utilisation par un Pod et les volumes persistants (PV) liĂ©s aux PVC ne sont pas supprimĂ©es du systĂšme, car cela peut entraĂźner des pertes de donnĂ©es. + +{{< note >}} +Le PVC est utilisĂ© activement par un pod lorsqu'il existe un objet Pod qui utilise le PVC. +{{< /note >}} + +Si un utilisateur supprime un PVC en cours d'utilisation par un pod, le PVC n'est pas supprimĂ© immĂ©diatement. +L'Ă©limination du PVC est diffĂ©rĂ©e jusqu'Ă  ce que le PVC ne soit plus activement utilisĂ© par les pods. +De plus, si un administrateur supprime un PV liĂ© Ă  un PVC, le PV n'est pas supprimĂ© immĂ©diatement. +L'Ă©limination du PV est diffĂ©rĂ©e jusqu'Ă  ce que le PV ne soit plus liĂ© Ă  un PVC. + +Vous pouvez voir qu'un PVC est protĂ©gĂ© lorsque son Ă©tat est `Terminating` et la liste `Finalizers` inclus `kubernetes.io/pvc-protection`: + +```text +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +Vous pouvez voir qu'un PV est protĂ©gĂ© lorsque son Ă©tat est `Terminating` et la liste `Finalizers` inclus `kubernetes.io/pv-protection` aussi: + +```text +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Available +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### RĂ©cupĂ©ration des volumes + +Lorsqu'un utilisateur a terminĂ© avec son volume, il peut supprimer les objets PVC de l'API qui permet la rĂ©cupĂ©ration de la ressource. +La politique de rĂ©cupĂ©ration pour un `PersistentVolume` indique au cluster ce qu'il doit faire du volume une fois qu'il a Ă©tĂ© libĂ©rĂ© de son PVC. +Actuellement, les volumes peuvent ĂȘtre conservĂ©s, recyclĂ©s ou supprimĂ©s. + +#### Volumes conservĂ©s + +La politique de rĂ©cupĂ©ration `Retain` permet la rĂ©cupĂ©ration manuelle de la ressource. +Lorsque le `PersistentVolumeClaim` est supprimĂ©, le `PersistentVolume` existe toujours et le volume est considĂ©rĂ© comme «libĂ©ré». +Mais il n'est pas encore disponible pour une autre demande car les donnĂ©es du demandeur prĂ©cĂ©dent restent sur le volume. +Un administrateur peut rĂ©cupĂ©rer manuellement le volume en procĂ©dant comme suit. + +1. Supprimer le `PersistentVolume`. + L'actif de stockage associĂ© dans une infrastructure externe (comme un volume AWS EBS, GCE PD, Azure Disk ou Cinder) existe toujours aprĂšs la suppression du PV. +1. Nettoyez manuellement les donnĂ©es sur l'actif de stockage associĂ© en consĂ©quence. +1. Supprimez manuellement l'actif de stockage associĂ© ou, si vous souhaitez rĂ©utiliser le mĂȘme actif de stockage, crĂ©ez un nouveau `PersistentVolume` avec la dĂ©finition de l'actif de stockage. + +#### Volumes supprimĂ©s + +Pour les plug-ins de volume qui prennent en charge la stratĂ©gie de rĂ©cupĂ©ration `Delete`, la suppression supprime Ă  la fois l'objet `PersistentVolume` de Kubernetes, ainsi que l'actif de stockage associĂ© dans l'infrastructure externe, tel qu'un volume AWS EBS, GCE PD, Azure Disk ou Cinder. +Les volumes qui ont Ă©tĂ© dynamiquement provisionnĂ©s hĂ©ritent de la [politique de rĂ©cupĂ©ration de leur `StorageClass`](#politique-de-rĂ©cupĂ©ration), qui par dĂ©faut est `Delete`. +L'administrateur doit configurer la `StorageClass` selon les attentes des utilisateurs; sinon, le PV doit ĂȘtre Ă©ditĂ© ou corrigĂ© aprĂšs sa crĂ©ation. +Voir [Modifier la politique de rĂ©cupĂ©ration d'un PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Volumes recyclĂ©s + +{{< warning >}} +La politique de rĂ©cupĂ©ration `Recycle` est obsolĂšte. +Au lieu de cela, l'approche recommandĂ©e consiste Ă  utiliser l'approvisionnement dynamique. +{{< /warning >}} + +Si elle est prise en charge par le plug-in de volume sous-jacent, la stratĂ©gie de rĂ©cupĂ©ration `Recycle` effectue un nettoyage de base (`rm -rf /thevolume/*`) sur le volume et le rend Ă  nouveau disponible pour une nouvelle demande. + +Cependant, un administrateur peut configurer un modĂšle de module de recyclage personnalisĂ© Ă  l'aide des arguments de ligne de commande du gestionnaire de contrĂŽleur Kubernetes, comme dĂ©crit [ici](/docs/admin/kube-controller-manager/). +Le modĂšle de pod de recycleur personnalisĂ© doit contenir une dĂ©finition de `volumes`, comme le montre l'exemple ci-dessous: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "k8s.gcr.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +Cependant, le chemin particulier spĂ©cifiĂ© dans la partie `volumes` du template personnalisĂ© de Pod est remplacĂ©e par le chemin particulier du volume qui est recyclĂ©. + +### Redimensionnement des PVC + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +La prise en charge du redimensionnement des PersistentVolumeClaims (PVCs) est dĂ©sormais activĂ©e par dĂ©faut. +Vous pouvez redimensionner les types de volumes suivants: + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* CSI + +Vous ne pouvez redimensionner un PVC que si le champ `allowVolumeExpansion` de sa classe de stockage est dĂ©fini sur true. + +``` yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restuser: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +Pour demander un volume plus important pour un PVC, modifiez l'objet PVC et spĂ©cifiez une taille plus grande. +Cela dĂ©clenche l'expansion du volume qui soutient le `PersistentVolume` sous-jacent. +Un nouveau `PersistentVolume` n'est jamais crĂ©Ă© pour satisfaire la demande. +Au lieu de cela, un volume existant est redimensionnĂ©. + +#### Redimensionnement de volume CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +La prise en charge du redimensionnement des volumes CSI est activĂ©e par dĂ©faut, mais elle nĂ©cessite Ă©galement un pilote CSI spĂ©cifique pour prendre en charge le redimensionnement des volumes. +Reportez-vous Ă  la documentation du pilote CSI spĂ©cifique pour plus d'informations. + +#### Redimensionner un volume contenant un systĂšme de fichiers + +Vous ne pouvez redimensionner des volumes contenant un systĂšme de fichiers que si le systĂšme de fichiers est XFS, Ext3 ou Ext4. + +Lorsqu'un volume contient un systĂšme de fichiers, le systĂšme de fichiers n'est redimensionnĂ© que lorsqu'un nouveau pod utilise le `PersistentVolumeClaim` en mode ReadWrite. +L'extension du systĂšme de fichiers est effectuĂ©e au dĂ©marrage d'un pod ou lorsqu'un pod est en cours d'exĂ©cution et que le systĂšme de fichiers sous-jacent prend en charge le redimensionnement en ligne. + +FlexVolumes autorise le redimensionnement si le pilote est dĂ©fini avec la capacitĂ© `requiresFSResize` sur `true`. +Le FlexVolume peut ĂȘtre redimensionnĂ© au redĂ©marrage du pod. + +#### Redimensionnement d'un PersistentVolumeClaim en cours d'utilisation + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +{{< note >}} +Redimensionner un PVCs Ă  chaud est disponible en version bĂȘta depuis Kubernetes 1.15 et en version alpha depuis 1.11. +La fonctionnalitĂ© `ExpandInUsePersistentVolumes` doit ĂȘtre activĂ©e, ce qui est le cas automatiquement pour de nombreux clusters de fonctionnalitĂ©s bĂȘta. +Se rĂ©fĂ©rer Ă  la documentation de la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) pour plus d'informations. +{{< /note >}} + +Dans ce cas, vous n'avez pas besoin de supprimer et de recrĂ©er un pod ou un dĂ©ploiement qui utilise un PVC existant. +Tout PVC en cours d'utilisation devient automatiquement disponible pour son pod dĂšs que son systĂšme de fichiers a Ă©tĂ© Ă©tendu. +Cette fonctionnalitĂ© n'a aucun effet sur les PVC qui ne sont pas utilisĂ©s par un pod ou un dĂ©ploiement. +Vous devez crĂ©er un pod qui utilise le PVC avant que l'extension puisse se terminer. + +Semblable Ă  d'autres types de volume - les volumes FlexVolume peuvent Ă©galement ĂȘtre Ă©tendus lorsqu'ils sont utilisĂ©s par un pod. + +{{< note >}} +Le redimensionnement de FlexVolume n'est possible que lorsque le pilote sous-jacent prend en charge le redimensionnement. +{{< /note >}} + +{{< note >}} +L'augmentation des volumes EBS est une opĂ©ration longue. +En outre, il existe un quota par volume d'une modification toutes les 6 heures. +{{< /note >}} + +## Types de volumes persistants + +Les types `PersistentVolume` sont implĂ©mentĂ©s en tant que plugins. +Kubernetes prend actuellement en charge les plugins suivants: + +* GCEPersistentDisk +* AWSElasticBlockStore +* AzureFile +* AzureDisk +* CSI +* FC (Fibre Channel) +* FlexVolume +* Flocker +* NFS +* iSCSI +* RBD (Ceph Block Device) +* CephFS +* Cinder (OpenStack block storage) +* Glusterfs +* VsphereVolume +* Quobyte Volumes +* HostPath (Test de nƓud unique uniquement -- le stockage local n'est en aucun cas pris en charge et NE FONCTIONNERA PAS dans un cluster Ă  plusieurs nƓuds) +* Portworx Volumes +* ScaleIO Volumes +* StorageOS + +## Volumes persistants + +Chaque PV contient une spĂ©cification et un Ă©tat, qui sont les spĂ©cifications et l'Ă©tat du volume. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Recycle + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +### CapacitĂ© + +GĂ©nĂ©ralement, un PV aura une capacitĂ© de stockage spĂ©cifique. +Ceci est rĂ©glĂ© en utilisant l'attribut `capacity` des PV. +Voir le Kubernetes [modĂšle de ressource](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) pour comprendre les unitĂ©s attendues par `capacity`. + +Actuellement, la taille du stockage est la seule ressource qui peut ĂȘtre dĂ©finie ou demandĂ©e. +Les futurs attributs peuvent inclure les IOPS, le dĂ©bit, etc. + +### Mode volume + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + +Avant Kubernetes 1.9, tous les plug-ins de volume crĂ©aient un systĂšme de fichiers sur le volume persistant. +Maintenant, vous pouvez dĂ©finir la valeur de `volumeMode` sur `block` pour utiliser un pĂ©riphĂ©rique de bloc brut, ou `filesystem` pour utiliser un systĂšme de fichiers. +`filesystem` est la valeur par dĂ©faut si la valeur est omise. +Il s'agit d'un paramĂštre API facultatif. + +### Modes d'accĂšs + +Un `PersistentVolume` peut ĂȘtre montĂ© sur un hĂŽte de n'importe quelle maniĂšre prise en charge par le fournisseur de ressources. +Comme indiquĂ© dans le tableau ci-dessous, les fournisseurs auront des capacitĂ©s diffĂ©rentes et les modes d'accĂšs de chaque PV sont dĂ©finis sur les modes spĂ©cifiques pris en charge par ce volume particulier. +Par exemple, NFS peut prendre en charge plusieurs clients en lecture/Ă©criture, mais un PV NFS spĂ©cifique peut ĂȘtre exportĂ© sur le serveur en lecture seule. +Chaque PV dispose de son propre ensemble de modes d'accĂšs dĂ©crivant les capacitĂ©s spĂ©cifiques de ce PV. + +Les modes d'accĂšs sont: + +* ReadWriteOnce -- le volume peut ĂȘtre montĂ© en lecture-Ă©criture par un seul nƓud +* ReadOnlyMany -- le volume peut ĂȘtre montĂ© en lecture seule par plusieurs nƓuds +* ReadWriteMany -- le volume peut ĂȘtre montĂ© en lecture-Ă©criture par de nombreux nƓuds + +Dans la CLI, les modes d'accĂšs sont abrĂ©gĂ©s comme suit: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany + +> __Important!__ Un volume ne peut ĂȘtre montĂ© qu'en utilisant un seul mode d'accĂšs Ă  la fois, mĂȘme s'il prend en charge plusieurs. + Par exemple, un GCEPersistentDisk peut ĂȘtre montĂ© en tant que ReadWriteOnce par un seul nƓud ou ReadOnlyMany par plusieurs nƓuds, mais pas en mĂȘme temps. + +| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | +|-:--------------------|-:-:--------------|-:-:--------------|-:-:----------------------------------------------| +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| CSI | dĂ©pend du pilote | dĂ©pend du pilote | dĂ©pend du pilote | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | dĂ©pend du pilote | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - (fonctionne lorsque les pods sont colocalisĂ©s) | +| PortworxVolume | ✓ | - | ✓ | +| ScaleIO | ✓ | ✓ | - | +| StorageOS | ✓ | - | - | + +### Classe + +Un PV peut avoir une classe, qui est spĂ©cifiĂ©e en dĂ©finissant l'attribut `storageClassName` sur le nom d'une [StorageClass](/docs/concepts/storage/storage-classes/). +Un PV d'une classe particuliĂšre ne peut ĂȘtre liĂ© qu'Ă  des PVC demandant cette classe. +Un PV sans `storageClassName` n'a pas de classe et ne peut ĂȘtre liĂ© qu'Ă  des PVC qui ne demandent aucune classe particuliĂšre. + +Dans le passĂ©, l'annotation `volume.beta.kubernetes.io/storage-class` a Ă©tĂ© utilisĂ© Ă  la place de l'attribut `storageClassName`. +Cette annotation fonctionne toujours; cependant, il deviendra complĂštement obsolĂšte dans une future version de Kubernetes. + +### Politique de rĂ©cupration + +Les politiques de rĂ©cupĂ©ration actuelles sont: + +* Retain -- remise en Ă©tat manuelle +* Recycle -- effacement de base (`rm -rf /thevolume/*`) +* Delete -- l'Ă©lĂ©ment de stockage associĂ© tel qu'AWS EBS, GCE PD, Azure Disk ou le volume OpenStack Cinder est supprimĂ© + +Actuellement, seuls NFS et HostPath prennent en charge le recyclage. +Les volumes AWS EBS, GCE PD, Azure Disk et Cinder prennent en charge la suppression. + +### Options de montage + +Un administrateur Kubernetes peut spĂ©cifier des options de montage supplĂ©mentaires pour quand un `PersistentVolume` est montĂ© sur un nƓud. + +{{< note >}} +Tous les types de volumes persistants ne prennent pas en charge les options de montage. +{{< /note >}} + +Les types de volume suivants prennent en charge les options de montage: + +* AWSElasticBlockStore +* AzureDisk +* AzureFile +* CephFS +* Cinder (OpenStack block storage) +* GCEPersistentDisk +* Glusterfs +* NFS +* Quobyte Volumes +* RBD (Ceph Block Device) +* StorageOS +* VsphereVolume +* iSCSI + +Les options de montage ne sont pas validĂ©es, donc le montage Ă©chouera simplement si l'une n'est pas valide. + +Dans le passĂ©, l'annotation `volume.beta.kubernetes.io/mount-options` Ă©tait utilisĂ©e Ă  la place de l'attribut `mountOptions`. +Cette annotation fonctionne toujours; cependant, elle deviendra complĂštement obsolĂšte dans une future version de Kubernetes. + +### AffinitĂ© des nƓuds + +{{< note >}} +Pour la plupart des types de volume, vous n'avez pas besoin de dĂ©finir ce champ. +Il est automatiquement rempli pour les volumes bloc de type [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) et [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). +Vous devez dĂ©finir explicitement ceci pour les volumes [locaux](/docs/concepts/storage/volumes/#local). +{{< /note >}} + +Un PV peut spĂ©cifier une [affinitĂ© de nƓud](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) pour dĂ©finir les contraintes qui limitent les nƓuds Ă  partir desquels ce volume est accessible. +Les pods qui utilisent un PV seront uniquement planifiĂ©s sur les nƓuds sĂ©lectionnĂ©s par l'affinitĂ© de nƓud. + +### Phase + +Un volume sera dans l'une des phases suivantes: + +* Available -- une ressource libre qui n'est pas encore liĂ©e Ă  une demande +* Bound -- le volume est liĂ© Ă  une demande +* Released -- la demande a Ă©tĂ© supprimĂ©e, mais la ressource n'est pas encore rĂ©cupĂ©rĂ©e par le cluster +* Failed -- le volume n'a pas rĂ©ussi sa rĂ©cupĂ©ration automatique + +Le CLI affichera le nom du PVC liĂ© au PV. + +## PersistentVolumeClaims + +Chaque PVC contient une spĂ©cification et un Ă©tat, qui sont les spĂ©cifications et l'Ă©tat de la rĂ©clamation. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Modes d'accĂšs + +Les PVC utilisent les mĂȘmes conventions que les volumes lorsque vous demandez un stockage avec des modes d'accĂšs spĂ©cifiques. + +### Modes de volume + +Les PVC utilisent la mĂȘme convention que les volumes pour indiquer la consommation du volume en tant que systĂšme de fichiers ou pĂ©riphĂ©rique de bloc. + +### Ressources + +Les PVC, comme les pods, peuvent demander des quantitĂ©s spĂ©cifiques d'une ressource. +Dans ce cas, la demande concerne le stockage. +Le mĂȘme [modĂšle de ressource](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) s'applique aux volumes et aux PVC. + +### SĂ©lecteur + +Les PVC peuvent spĂ©cifier un [sĂ©lecteur de labels](/docs/concepts/overview/working-with-objects/labels/#label-selectors) pour filtrer davantage l'ensemble des volumes. +Seuls les volumes dont les Ă©tiquettes correspondent au sĂ©lecteur peuvent ĂȘtre liĂ©s au PVC. +Le sĂ©lecteur peut comprendre deux champs: + +* `matchLabels` - le volume doit avoir un label avec cette valeur +* `matchExpressions` - une liste des exigences dĂ©finies en spĂ©cifiant la clĂ©, la liste des valeurs et l'opĂ©rateur qui relie la clĂ© et les valeurs. + Les opĂ©rateurs valides incluent In, NotIn, Exists et DoesNotExist. + +Toutes les exigences, Ă  la fois de `matchLabels` et de `matchExpressions` doivent toutes ĂȘtre satisfaites pour correspondre (application d'un opĂ©rateur boolĂ©en ET). + +### Classe + +Un PVC peut demander une classe particuliĂšre en spĂ©cifiant le nom d'une [StorageClass](/docs/concepts/storage/storage-classes/) en utilisant l'attribut `storageClassName`. +Seuls les PV de la classe demandĂ©e, ceux ayant le mĂȘme `storageClassName` que le PVC, peuvent ĂȘtre liĂ©s au PVC. + +Les PVC n'ont pas nĂ©cessairement Ă  demander une classe. +Un PVC avec son attribut `storageClassName` Ă©gal Ă  `""` est toujours interprĂ©tĂ© comme demandant un PV sans classe, il ne peut donc ĂȘtre liĂ© qu'Ă  des PV sans classe (pas d'annotation ou une annotation Ă©gal Ă  `""`). +Un PVC sans `storageClassName` n'est pas tout Ă  fait la mĂȘme et est traitĂ© diffĂ©remment par le cluster, selon que le [`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) est activĂ©. + +* Si le plug-in d'admission est activĂ©, l'administrateur peut spĂ©cifier une valeur par dĂ©faut `StorageClass`. + Tous les PVC qui n'ont pas de `storageClassName` ne peuvent ĂȘtre liĂ©s qu'aux PV de cette valeur par dĂ©faut. + La spĂ©cification d'une `StorageClass` par dĂ©faut se fait en dĂ©finissant l'annotation `storageclass.kubernetes.io/is-default-class` Ă©gal Ă  `true` dans un objet `StorageClass`. + Si l'administrateur ne spĂ©cifie pas de valeur par dĂ©faut, le cluster rĂ©pond Ă  la crĂ©ation de PVC comme si le plug-in d'admission Ă©tait dĂ©sactivĂ©. + Si plusieurs valeurs par dĂ©faut sont spĂ©cifiĂ©es, le plugin d'admission interdit la crĂ©ation de tous les PVC. +* Si le plugin d'admission est dĂ©sactivĂ©, il n'y a aucune notion de dĂ©faut `StorageClass`. + Tous les PVC qui n'ont pas `storageClassName` peut ĂȘtre liĂ© uniquement aux PV qui n'ont pas de classe. + Dans ce cas, les PVC qui n'ont pas `storageClassName` sont traitĂ©s de la mĂȘme maniĂšre que les PVC qui ont leur `storageClassName` Ă©gal Ă  `""`. + +Selon la mĂ©thode d'installation, une `StorageClass` par dĂ©faut peut ĂȘtre dĂ©ployĂ©e sur un cluster Kubernetes par le gestionnaire d'extensions pendant l'installation. + +Lorsqu'un PVC spĂ©cifie un `selector` en plus de demander une `StorageClass`, les exigences sont ET ensemble: seul un PV de la classe demandĂ©e et avec les labels demandĂ©es peut ĂȘtre liĂ© au PVC. + +{{< note >}} +Actuellement, un PVC avec un `selector` non vide ne peut pas avoir un PV provisionnĂ© dynamiquement pour cela. +{{< /note >}} + +Dans le passĂ©, l'annotation `volume.beta.kubernetes.io/storage-class` a Ă©tĂ© utilisĂ© au lieu de l'attribut `storageClassName`. +Cette annotation fonctionne toujours; cependant, elle ne sera pas pris en charge dans une future version de Kubernetes. + +## PVC sous forme de volumes + +Les pods accĂšdent au stockage en utilisant le PVC comme volume. +Les PVC et les pods qui les utilisent doivent exister dans le mĂȘme namespace. +Le cluster trouve le PVC dans le namespace oĂč se trouve le pod et l'utilise pour obtenir le `PersistentVolume` visĂ© par le PVC. +Le volume est ensuite montĂ© sur l'hĂŽte et dans le pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### Remarque au sujet des namespaces + +Les liaisons `PersistentVolumes` sont exclusives, et comme les objets `PersistentVolumeClaims` sont des objets vivant dans un namespace donnĂ©, le montage de PVC avec les modes "Many" (`ROX`, `RWX`) n'est possible qu'au sein d'un mĂȘme namespace. + +## Prise en charge du volume de bloc brut + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + +Les plug-ins de volume suivants prennent en charge les volumes de blocs bruts, y compris l'approvisionnement dynamique, le cas Ă©chĂ©ant: + +* AWSElasticBlockStore +* AzureDisk +* FC (Fibre Channel) +* GCEPersistentDisk +* iSCSI +* Local volume +* RBD (Ceph Block Device) +* VsphereVolume (alpha) + +{{< note >}} +Seuls les volumes FC et iSCSI prennent en charge les volumes de blocs bruts dans Kubernetes 1.9. +La prise en charge des plugins supplĂ©mentaires a Ă©tĂ© ajoutĂ©e dans 1.10. +{{< /note >}} + +### Volumes persistants utilisant un volume de bloc brut + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### Revendication de volume persistant demandant un volume de bloc brut + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + +### SpĂ©cification de pod ajoutant le chemin du pĂ©riphĂ©rique de bloc brut dans le conteneur + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} +Lorsque vous ajoutez un pĂ©riphĂ©rique de bloc brut pour un pod, vous spĂ©cifiez le chemin de pĂ©riphĂ©rique dans le conteneur au lieu d'un chemin de montage. +{{< /note >}} + +### Lier des volumes bloc bruts + +Si un utilisateur demande un volume de bloc brut en l'indiquant Ă  l'aide du champ `volumeMode` dans la spĂ©cification `PersistentVolumeClaim`, les rĂšgles de liaison diffĂšrent lĂ©gĂšrement des versions prĂ©cĂ©dentes qui ne considĂ©raient pas ce mode comme faisant partie de la spĂ©cification. +Voici un tableau des combinaisons possibles que l'utilisateur et l'administrateur peuvent spĂ©cifier pour demander un pĂ©riphĂ©rique de bloc brut. +Le tableau indique si le volume sera liĂ© ou non compte tenu des combinaisons: +Matrice de liaison de volume pour les volumes provisionnĂ©s statiquement: + +| PV volumeMode | PVC volumeMode | Result | +|---------------|-:-:------------|--:------| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} +Seuls les volumes provisionnĂ©s statiquement sont pris en charge pour la version alpha. +Les administrateurs doivent prendre en compte ces valeurs lorsqu'ils travaillent avec des pĂ©riphĂ©riques de bloc brut. +{{< /note >}} + +## Snapshot et restauration de volumes + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +La fonction de snapshot de volume a Ă©tĂ© ajoutĂ©e pour prendre en charge uniquement les plug-ins de volume CSI. +Pour plus de dĂ©tails, voir [volume snapshots](/docs/concepts/storage/volume-snapshots/). + +Pour activer la prise en charge de la restauration d'un volume Ă  partir d'un snapshot de volume, activez la fonctionnalitĂ© `VolumeSnapshotDataSource` sur l'apiserver et le controller-manager. + +### CrĂ©er du PVC Ă  partir d'un snapshot de volume + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Clonage de volume + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +La fonctionnalitĂ© de clonage de volume a Ă©tĂ© ajoutĂ©e pour prendre en charge uniquement les plug-ins de volume CSI. +Pour plus de dĂ©tails, voir [clonage de volume](/docs/concepts/storage/volume-pvc-datasource/). + +Pour activer la prise en charge du clonage d'un volume Ă  partir d'une source de donnĂ©es PVC, activez la propriĂ©tĂ© `VolumePVCDataSource` sur l'apiserver et le controller-manager. + +### CrĂ©er un PVC Ă  partir d'un PVC existant + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Écriture d'une configuration portable + +Si vous Ă©crivez des templates de configuration ou des exemples qui s'exĂ©cutent sur une large gamme de clusters et nĂ©cessitent un stockage persistant, il est recommandĂ© d'utiliser le modĂšle suivant: + +* Incluez des objets `PersistentVolumeClaim` dans votre ensemble de config (aux cĂŽtĂ©s de `Deployments`, `ConfigMaps`, etc.). +* N'incluez pas d'objets `PersistentVolume` dans la configuration, car l'utilisateur qui instancie la configuration peut ne pas ĂȘtre autorisĂ© Ă  crĂ©er des `PersistentVolumes`. +* Donnez Ă  l'utilisateur la possibilitĂ© de fournir un nom de classe de stockage lors de l'instanciation du template. + * Si l'utilisateur fournit un nom de classe de stockage, mettez cette valeur dans le champ `persistentVolumeClaim.storageClassName`. + Cela entraĂźnera le PVC pour utiliser la bonne classe de stockage si le cluster a cette `StorageClasses` activĂ© par l'administrateur. + * Si l'utilisateur ne fournit pas de nom de classe de stockage, laissez le champ `persistentVolumeClaim.storageClassName` Ă  zĂ©ro. + Cela entraĂźnera un PV Ă  ĂȘtre automatiquement provisionnĂ© pour l'utilisateur avec la `StorageClass` par dĂ©faut dans le cluster. + De nombreux environnements de cluster ont une `StorageClass` par dĂ©faut installĂ©e, oĂč les administrateurs peuvent crĂ©er leur propre `StorageClass` par dĂ©faut. +* Dans votre outillage, surveillez les PVCs qui ne sont pas liĂ©s aprĂšs un certain temps et signalez-le Ă  l'utilisateur, car cela peut indiquer que le cluster n'a pas de support de stockage dynamique (auquel cas l'utilisateur doit crĂ©er un PV correspondant) ou que le cluster n'a aucun systĂšme de stockage (auquel cas l'utilisateur ne peut pas dĂ©ployer de configuration nĂ©cessitant des PVCs). + +{{% /capture %}} diff --git a/content/fr/docs/concepts/workloads/controllers/deployment.md b/content/fr/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..4e6fb3bda5 --- /dev/null +++ b/content/fr/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1225 @@ +--- +title: DĂ©ploiements +feature: + title: DĂ©ploiements et restaurations automatisĂ©s + description: > + Kubernetes dĂ©ploie progressivement les modifications apportĂ©es Ă  votre application ou Ă  sa configuration, tout en surveillant l'intĂ©gritĂ© de l'application pour vous assurer qu'elle ne tue pas toutes vos instances en mĂȘme temps. + En cas de problĂšme, Kubernetes annulera le changement pour vous. + Profitez d'un Ă©cosystĂšme croissant de solutions de dĂ©ploiement. + +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Un _Deployment_ (dĂ©ploiement en français) fournit des mises Ă  jour dĂ©claratives pour [Pods](/fr/docs/concepts/workloads/pods/pod/) et [ReplicaSets](/fr/docs/concepts/workloads/controllers/replicaset/). + +Vous dĂ©crivez un _Ă©tat dĂ©sirĂ©_ dans un dĂ©ploiement et le {{< glossary_tooltip term_id="controller" text="controlleur">}} dĂ©ploiement change l'Ă©tat rĂ©el Ă  l'Ă©tat souhaitĂ© Ă  un rythme contrĂŽlĂ©. +Vous pouvez dĂ©finir des Deployments pour crĂ©er de nouveaux ReplicaSets, ou pour supprimer des dĂ©ploiements existants et adopter toutes leurs ressources avec de nouveaux dĂ©ploiements. + +{{< note >}} +Ne gĂ©rez pas les ReplicaSets appartenant Ă  un Deployment. +Pensez Ă  ouvrir un ticket dans le dĂ©pot Kubernetes principal si votre cas d'utilisation n'est pas traitĂ© ci-dessous. +{{< /note >}} + +{{% /capture %}} + +{{% capture body %}} + +## Cas d'utilisation + +Voici des cas d'utilisation typiques pour les dĂ©ploiements: + +* [CrĂ©er un dĂ©ploiement pour dĂ©ployer un ReplicaSet](#crĂ©ation-dun-dĂ©ploiement). + Le ReplicaSet crĂ©e des pods en arriĂšre-plan. + VĂ©rifiez l'Ă©tat du dĂ©ploiement pour voir s'il rĂ©ussit ou non. +* [DĂ©clarez le nouvel Ă©tat des Pods](#mise-Ă -jour-dun-dĂ©ploiement) en mettant Ă  jour le PodTemplateSpec du dĂ©ploiement. + Un nouveau ReplicaSet est crĂ©Ă© et le dĂ©ploiement gĂšre le dĂ©placement des pods de l'ancien ReplicaSet vers le nouveau Ă  un rythme contrĂŽlĂ©. + Chaque nouveau ReplicaSet met Ă  jour la rĂ©vision du dĂ©ploiement. +* [Revenir Ă  une rĂ©vision de dĂ©ploiement antĂ©rieure](#annulation-dun-dĂ©ploiement) si l'Ă©tat actuel du dĂ©ploiement n'est pas stable. + Chaque restauration met Ă  jour la rĂ©vision du dĂ©ploiement. +* [Augmentez le dĂ©ploiement pour traiter plus de charge](#mise-Ă -lĂ©chelle-dun-dĂ©ploiement). +* [Suspendre le dĂ©ploiement](#pause-et-reprise-dun-dĂ©ploiement) d'appliquer plusieurs correctifs Ă  son PodTemplateSpec, puis de le reprendre pour dĂ©marrer un nouveau dĂ©ploiement. +* [Utiliser l'Ă©tat du dĂ©ploiement](#statut-de-dĂ©ploiement) comme indicateur qu'un dĂ©ploiement est bloquĂ©. +* [Nettoyer les anciens ReplicaSets](#politique-de-nettoyage) dont vous n'avez plus besoin. + +## CrĂ©ation d'un dĂ©ploiement + +Voici un exemple de dĂ©ploiement. +Il crĂ©e un ReplicaSet pour faire apparaĂźtre trois pods `nginx`: + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +Dans cet exemple: + +* Un dĂ©ploiement nommĂ© `nginx-deployment` est crĂ©Ă©, indiquĂ© par le champ `.metadata.name`. +* Le dĂ©ploiement crĂ©e trois pods rĂ©pliquĂ©s, indiquĂ©s par le champ `replicas`. +* Le champ `selector` dĂ©finit comment le dĂ©ploiement trouve les pods Ă  gĂ©rer. + Dans ce cas, vous sĂ©lectionnez simplement un label dĂ©finie dans le template de pod (`app:nginx`). + Cependant, des rĂšgles de sĂ©lection plus sophistiquĂ©es sont possibles, tant que le modĂšle de pod satisfait lui-mĂȘme la rĂšgle. + + {{< note >}} + Le champ `matchLabels` est une table de hash {clĂ©, valeur}. + Une seule {clĂ©, valeur} dans la table `matchLabels` est Ă©quivalente Ă  un Ă©lĂ©ment de `matchExpressions`, dont le champ clĂ© est "clĂ©", l'opĂ©rateur est "In" et le tableau de valeurs contient uniquement "valeur". + Toutes les exigences, Ă  la fois de `matchLabels` et de `matchExpressions`, doivent ĂȘtre satisfaites pour correspondre. + {{< /note >}} + +* Le champ `template` contient les sous-champs suivants: + * Les Pods reçoivent le label `app:nginx` dans le champ `labels`. + * La spĂ©cification du template de pod dans le champ `.template.spec`, indique que les pods exĂ©cutent un conteneur, `nginx`, qui utilise l'image `nginx` [Docker Hub](https://hub.docker.com/) Ă  la version 1.7.9. + * CrĂ©ez un conteneur et nommez-le `nginx` en utilisant le champ `name`. + +Suivez les Ă©tapes ci-dessous pour crĂ©er le dĂ©ploiement ci-dessus: + +Avant de commencer, assurez-vous que votre cluster Kubernetes est opĂ©rationnel. + +1. CrĂ©ez le dĂ©ploiement en exĂ©cutant la commande suivante: + + {{< note >}} + Vous pouvez spĂ©cifier l'indicateur `--record` pour Ă©crire la commande exĂ©cutĂ©e dans l'annotation de ressource `kubernetes.io/change-cause`. + C'est utile pour une future introspection. + Par exemple, pour voir les commandes exĂ©cutĂ©es dans chaque rĂ©vision de dĂ©ploiement. + {{< /note >}} + + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` + +1. ExĂ©cutez `kubectl get deployments` pour vĂ©rifier si le dĂ©ploiement a Ă©tĂ© crĂ©Ă©. + Si le dĂ©ploiement est toujours en cours de crĂ©ation, la sortie est similaire Ă : + + ```shell + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s + ``` + + Lorsque vous inspectez les dĂ©ploiements de votre cluster, les champs suivants s'affichent: + + * `NAME` rĂ©pertorie les noms des dĂ©ploiements dans le cluster. + * `DESIRED` affiche le nombre souhaitĂ© de _rĂ©pliques_ de l'application, que vous dĂ©finissez lorsque vous crĂ©ez le dĂ©ploiement. + C'est l'_Ă©tat dĂ©sirĂ©_. + * `CURRENT` affiche le nombre de rĂ©plicas en cours d'exĂ©cution. + * `UP-TO-DATE` affiche le nombre de rĂ©plicas qui ont Ă©tĂ© mises Ă  jour pour atteindre l'Ă©tat souhaitĂ©. + * `AVAILABLE` affiche le nombre de rĂ©plicas de l'application disponibles pour vos utilisateurs. + * `AGE` affiche la durĂ©e d'exĂ©cution de l'application. + + Notez que le nombre de rĂ©plicas souhaitĂ©es est de 3 selon le champ `.spec.replicas`. + +1. Pour voir l'Ă©tat du dĂ©ploiement, exĂ©cutez: + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + +1. ExĂ©cutez Ă  nouveau `kubectl get deployments` quelques secondes plus tard. + La sortie est similaire Ă  ceci: + + ```text + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s + ``` + + Notez que le dĂ©ploiement a crĂ©Ă© les trois rĂ©pliques et que toutes les rĂ©pliques sont Ă  jour (elles contiennent le dernier modĂšle de pod) et disponibles. + +1. Pour voir le ReplicaSet (`rs`) crĂ©Ă© par le dĂ©ploiement, exĂ©cutez `kubectl get rs`. + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + + Notez que le nom du ReplicaSet est toujours formatĂ© comme: `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. + La chaĂźne alĂ©atoire est gĂ©nĂ©rĂ©e alĂ©atoirement et utilise le pod-template-hash comme graine. + +1. Pour voir les labels gĂ©nĂ©rĂ©es automatiquement pour chaque Pod, exĂ©cutez `kubectl get pods --show-labels`. + La sortie est similaire Ă  ceci: + + ```text + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + + Le ReplicaSet crĂ©Ă© garantit qu'il y a trois pods `nginx`. + +{{< note >}} +Vous devez spĂ©cifier un sĂ©lecteur appropriĂ© et des labels de template de pod dans un dĂ©ploiement (dans ce cas, `app: nginx`). +Ne superposez pas les Ă©tiquettes ou les sĂ©lecteurs avec d'autres contrĂŽleurs (y compris d'autres dĂ©ploiements et StatefulSets). +Kubernetes n'empĂȘche pas les chevauchements de noms, et si plusieurs contrĂŽleurs ont des sĂ©lecteurs qui se chevauchent, ces contrĂŽleurs peuvent entrer en conflit et se comporter de façon inattendue. +{{< /note >}} + +### Étiquette pod-template-hash + +{{< note >}} +Ne modifiez pas ce label. +{{< /note >}} + +Le label `pod-template-hash` est ajoutĂ©e par le contrĂŽleur de dĂ©ploiement Ă  chaque ReplicaSet crĂ©Ă© ou adoptĂ© par un dĂ©ploiement. + +Ce label garantit que les ReplicaSets enfants d'un dĂ©ploiement ne se chevauchent pas. +Il est gĂ©nĂ©rĂ© en hachant le `PodTemplate` du ReplicaSet et en utilisant le hachage rĂ©sultant comme valeur de label qui est ajoutĂ©e au sĂ©lecteur ReplicaSet, aux labels de template de pod et dans tous les pods existants que le ReplicaSet peut avoir. + +## Mise Ă  jour d'un dĂ©ploiement + +{{< note >}} +Le re-dĂ©ploiement d'un dĂ©ploiement est dĂ©clenchĂ© si et seulement si le modĂšle de pod du dĂ©ploiement (c'est-Ă -dire `.spec.template`) est modifiĂ©, par exemple si les labels ou les images de conteneur du template sont mis Ă  jour. +D'autres mises Ă  jour, telles que la mise Ă  l'Ă©chelle du dĂ©ploiement, ne dĂ©clenchent pas de rollout. +{{< /note >}} + +Suivez les Ă©tapes ci-dessous pour mettre Ă  jour votre dĂ©ploiement: + +1. Mettons Ă  jour les pods nginx pour utiliser l'image `nginx: 1.9.1` au lieu de l'image `nginx: 1.7.9`. + + ```shell + kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + + ou utilisez la commande suivante: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment image updated + ``` + + Alternativement, vous pouvez `Ă©diter` le dĂ©ploiement et changer `.spec.template.spec.containers[0].image` de `nginx: 1.7.9` Ă  `nginx: 1.9.1`: + + ```shell + kubectl edit deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment edited + ``` + +2. Pour voir l'Ă©tat du dĂ©ploiement, exĂ©cutez: + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + ``` + + ou + + ```text + deployment.apps/nginx-deployment successfully rolled out + ``` + +Obtenez plus de dĂ©tails sur votre dĂ©ploiement mis Ă  jour: + +* Une fois le dĂ©ploiement rĂ©ussi, vous pouvez afficher le dĂ©ploiement en exĂ©cutant `kubectl get deployments`. + La sortie est similaire Ă  ceci: + + ```text + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 36s + ``` + +* ExĂ©cutez `kubectl get rs` pour voir que le dĂ©ploiement a mis Ă  jour les pods en crĂ©ant un nouveau ReplicaSet et en le redimensionnant jusqu'Ă  3 replicas, ainsi qu'en rĂ©duisant l'ancien ReplicaSet Ă  0 rĂ©plicas. + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 6s + nginx-deployment-2035384211 0 0 0 36s + ``` + +* L'exĂ©cution de `kubectl get pods` ne devrait dĂ©sormais afficher que les nouveaux pods: + + ```shell + kubectl get pods + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-khku8 1/1 Running 0 14s + nginx-deployment-1564180365-nacti 1/1 Running 0 14s + nginx-deployment-1564180365-z9gth 1/1 Running 0 14s + ``` + + La prochaine fois que vous souhaitez mettre Ă  jour ces pods, il vous suffit de mettre Ă  jour le modĂšle de pod de dĂ©ploiement Ă  nouveau. + + Le dĂ©ploiement garantit que seul un certain nombre de pods sont en panne pendant leur mise Ă  jour. + Par dĂ©faut, il garantit qu'au moins 75% du nombre souhaitĂ© de pods sont en place (25% max indisponible). + + Le dĂ©ploiement garantit Ă©galement que seul un certain nombre de pods sont crĂ©Ă©s au-dessus du nombre souhaitĂ© de pods. + Par dĂ©faut, il garantit qu'au plus 125% du nombre de pods souhaitĂ© sont en hausse (surtension maximale de 25%). + + Par exemple, si vous regardez attentivement le dĂ©ploiement ci-dessus, vous verrez qu'il a d'abord crĂ©Ă© un nouveau pod, puis supprimĂ© certains anciens pods et en a crĂ©Ă© de nouveaux. + Il ne tue pas les anciens Pods tant qu'un nombre suffisant de nouveaux Pods n'est pas apparu, et ne crĂ©e pas de nouveaux Pods tant qu'un nombre suffisant de Pods anciens n'a pas Ă©tĂ© tuĂ©. + Il s'assure qu'au moins 2 pods sont disponibles et qu'au maximum 4 pods au total sont disponibles. + +* Obtenez les dĂ©tails de votre dĂ©ploiement: + + ```shell + kubectl describe deployments + ``` + + La sortie est similaire Ă  ceci: + + ```text + Name: nginx-deployment + Namespace: default + CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=2 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 + ``` + + Ici, vous voyez que lorsque vous avez crĂ©Ă© le dĂ©ploiement pour la premiĂšre fois, il a crĂ©Ă© un ReplicaSet (nginx-deployment-2035384211) et l'a mis Ă  l'Ă©chelle directement jusqu'Ă  3 rĂ©plicas. + Lorsque vous avez mis Ă  jour le dĂ©ploiement, il a crĂ©Ă© un nouveau ReplicaSet (nginx-deployment-1564180365) et l'a mis Ă  l'Ă©chelle jusqu'Ă  1, puis a rĂ©duit l'ancien ReplicaSet Ă  2, de sorte qu'au moins 2 pods Ă©taient disponibles et au plus 4 pods ont Ă©tĂ© crĂ©Ă©s Ă  chaque fois. + Il a ensuite poursuivi la montĂ©e en puissance du nouveau et de l'ancien ReplicaSet, avec la mĂȘme stratĂ©gie de mise Ă  jour continue. + Enfin, vous aurez 3 rĂ©plicas disponibles dans le nouveau ReplicaSet, et l'ancien ReplicaSet est rĂ©duit Ă  0. + +### Rollover (alias plusieurs mises Ă  jour en vol) {#rollover} + +Chaque fois qu'un nouveau dĂ©ploiement est observĂ© par le contrĂŽleur de dĂ©ploiement, un ReplicaSet est crĂ©Ă© pour afficher les pods souhaitĂ©s. +Si le dĂ©ploiement est mis Ă  jour, le ReplicaSet existant qui contrĂŽle les pods dont les Ă©tiquettes correspondent Ă  `.spec.selector` mais dont le modĂšle ne correspond pas Ă  `.spec.template` est rĂ©duit. +Finalement, le nouveau ReplicaSet est mis Ă  l'Ă©chelle Ă  `.spec.replicas` et tous les anciens ReplicaSets sont mis Ă  l'Ă©chelle Ă  0. + +Si vous mettez Ă  jour un dĂ©ploiement alors qu'un dĂ©ploiement existant est en cours, le dĂ©ploiement crĂ©e un nouveau ReplicaSet conformĂ©ment Ă  la mise Ă  jour et commence Ă  le mettre Ă  l'Ă©chelle, et arrĂȘte de mettre Ă  jour le ReplicaSet qu'il augmentait prĂ©cĂ©demment - il l'ajoutera Ă  sa liste de anciens ReplicaSets et commencera Ă  le rĂ©duire. + +Par exemple, supposons que vous crĂ©ez un dĂ©ploiement pour crĂ©er 5 rĂ©pliques de `nginx: 1.7.9`, puis mettez Ă  jour le dĂ©ploiement pour crĂ©er 5 rĂ©pliques de `nginx: 1.9.1`, alors que seulement 3 rĂ©pliques de `nginx:1.7.9` avait Ă©tĂ© crĂ©Ă©s. +Dans ce cas, le dĂ©ploiement commence immĂ©diatement Ă  tuer les 3 pods `nginx: 1.7.9` qu'il avait crĂ©Ă©s et commence Ă  crĂ©er des pods `nginx: 1.9.1`. +Il n'attend pas que les 5 rĂ©pliques de `nginx: 1.7.9` soient crĂ©Ă©es avant de changer de cap. + +### Mises Ă  jour du sĂ©lecteur de labels + +Il est gĂ©nĂ©ralement dĂ©conseillĂ© de mettre Ă  jour le sĂ©lecteur de labels et il est suggĂ©rĂ© de planifier vos sĂ©lecteurs Ă  l'avance. +Dans tous les cas, si vous devez effectuer une mise Ă  jour du sĂ©lecteur de labels, soyez trĂšs prudent et assurez-vous d'avoir saisi toutes les implications. + +{{< note >}} +Dans la version d'API `apps/v1`, le sĂ©lecteur de label d'un dĂ©ploiement est immuable aprĂšs sa crĂ©ation. +{{< /note >}} + +* Les ajouts de sĂ©lecteur nĂ©cessitent que les labels de template de pod dans la spĂ©cification de dĂ©ploiement soient Ă©galement mises Ă  jour avec les nouveaux labels, sinon une erreur de validation est renvoyĂ©e. + Cette modification ne se chevauche pas, ce qui signifie que le nouveau sĂ©lecteur ne sĂ©lectionne pas les ReplicaSets et les pods crĂ©Ă©s avec l'ancien sĂ©lecteur, ce qui entraĂźne la perte de tous les anciens ReplicaSets et la crĂ©ation d'un nouveau ReplicaSet. +* Les mises Ă  jour du sĂ©lecteur modifient la valeur existante dans une clĂ© de sĂ©lection - entraĂźnent le mĂȘme comportement que les ajouts. +* La suppression de sĂ©lecteur supprime une clĂ© existante du sĂ©lecteur de dĂ©ploiement - ne nĂ©cessite aucune modification dans les labels du template de pod. + Les ReplicaSets existants ne sont pas orphelins et aucun nouveau ReplicaSet n'est crĂ©Ă©, mais notez que le label supprimĂ© existe toujours dans tous les Pods et ReplicaSets existants. + +## Annulation d'un dĂ©ploiement + +Parfois, vous souhaiterez peut-ĂȘtre annuler un dĂ©ploiement; par exemple, lorsque le dĂ©ploiement n'est pas stable, comme en cas d'Ă©checs Ă  rĂ©pĂ©tition (CrashLoopBackOff). +Par dĂ©faut, tout l'historique des dĂ©ploiements d'un dĂ©ploiement est conservĂ© dans le systĂšme afin que vous puissiez le restaurer Ă  tout moment (vous pouvez le modifier en modifiant la limite de l'historique des rĂ©visions). + +{{< note >}} +La rĂ©vision d'un dĂ©ploiement est crĂ©Ă©e lorsque le dĂ©ploiement d'un dĂ©ploiement est dĂ©clenchĂ©. +Cela signifie qu'une nouvelle rĂ©vision est crĂ©Ă©e si et seulement si le template de pod de dĂ©ploiement (`.spec.template`) est modifiĂ©, par exemple si vous mettez Ă  jour les labels ou les images de conteneur du template. +D'autres mises Ă  jour, telles que la mise Ă  l'Ă©chelle du dĂ©ploiement, ne crĂ©ent pas de rĂ©vision de dĂ©ploiement, de sorte que vous puissiez faciliter la mise Ă  l'Ă©chelle manuelle ou automatique simultanĂ©e. +Cela signifie que lorsque vous revenez Ă  une rĂ©vision antĂ©rieure, seule la partie du template de pod de dĂ©ploiement est annulĂ©e. +{{< /note >}} + +* Supposons que vous ayez fait une faute de frappe lors de la mise Ă  jour du dĂ©ploiement, en mettant le nom de l'image sous la forme `nginx:1.91` au lieu de `nginx: 1.9.1`: + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment image updated + ``` + +* Le dĂ©ploiement est bloquĂ©. + Vous pouvez le vĂ©rifier en vĂ©rifiant l'Ă©tat du dĂ©ploiement: + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + Waiting for rollout to finish: 1 out of 3 new replicas have been updated... + ``` + +* Appuyez sur Ctrl-C pour arrĂȘter la surveillance d'Ă©tat de dĂ©ploiement ci-dessus. + Pour plus d'informations sur les dĂ©ploiements bloquĂ©s, [en savoir plus ici](#deployment-status). + +* Vous voyez que le nombre d'anciens rĂ©plicas (`nginx-deployment-1564180365` et `nginx-deployment-2035384211`) est 2, et les nouveaux rĂ©plicas (`nginx-deployment-3066724191`) est 1. + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 25s + nginx-deployment-2035384211 0 0 0 36s + nginx-deployment-3066724191 1 1 0 6s + ``` + +* En regardant les pods crĂ©Ă©s, vous voyez que 1 pod crĂ©Ă© par le nouveau ReplicaSet est coincĂ© dans une boucle pour rĂ©cupĂ©rer son image: + + ```shell + kubectl get pods + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-70iae 1/1 Running 0 25s + nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s + nginx-deployment-1564180365-hysrc 1/1 Running 0 25s + nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s + ``` + + {{< note >}} + Le contrĂŽleur de dĂ©ploiement arrĂȘte automatiquement le mauvais dĂ©ploiement et arrĂȘte la mise Ă  l'Ă©chelle du nouveau ReplicaSet. + Cela dĂ©pend des paramĂštres rollingUpdate (`maxUnavailable` spĂ©cifiquement) que vous avez spĂ©cifiĂ©s. + Kubernetes dĂ©finit par dĂ©faut la valeur Ă  25%. + {{< /note >}} + +* Obtenez la description du dĂ©ploiement: + + ```shell + kubectl describe deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 + Labels: app=nginx + Selector: app=nginx + Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) + NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 + ``` + + Pour rĂ©soudre ce problĂšme, vous devez revenir Ă  une version prĂ©cĂ©dente de Deployment qui est stable. + +### VĂ©rification de l'historique de dĂ©ploiement d'un dĂ©ploiement + +Suivez les Ă©tapes ci-dessous pour vĂ©rifier l'historique de dĂ©ploiement: + +1. Tout d'abord, vĂ©rifiez les rĂ©visions de ce dĂ©ploiement: + + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployments "nginx-deployment" + REVISION CHANGE-CAUSE + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true + 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + `CHANGE-CAUSE` est copiĂ© de l'annotation de dĂ©ploiement `kubernetes.io/change-cause` dans ses rĂ©visions lors de la crĂ©ation. + Vous pouvez spĂ©cifier le message`CHANGE-CAUSE` en: + + * Annoter le dĂ©ploiement avec `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image mis Ă  jour en 1.9.1"` + * Ajoutez le drapeau `--record` pour enregistrer la commande `kubectl` qui apporte des modifications Ă  la ressource. + * Modification manuelle du manifeste de la ressource. + +2. Pour voir les dĂ©tails de chaque rĂ©vision, exĂ©cutez: + + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. + ``` + +### Revenir Ă  une rĂ©vision prĂ©cĂ©dente + +Suivez les Ă©tapes ci-dessous pour restaurer le dĂ©ploiement de la version actuelle Ă  la version prĂ©cĂ©dente, qui est la version 2. + +1. Vous avez maintenant dĂ©cidĂ© d'annuler le dĂ©ploiement actuel et le retour Ă  la rĂ©vision prĂ©cĂ©dente: + + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment + ``` + + Alternativement, vous pouvez revenir Ă  une rĂ©vision spĂ©cifique en la spĂ©cifiant avec `--to-revision`: + + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment + ``` + + Pour plus de dĂ©tails sur les commandes liĂ©es au dĂ©ploiement, lisez [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + + Le dĂ©ploiement est maintenant rĂ©tabli Ă  une prĂ©cĂ©dente rĂ©vision stable. + Comme vous pouvez le voir, un Ă©vĂ©nement `DeploymentRollback` pour revenir Ă  la rĂ©vision 2 est gĂ©nĂ©rĂ© Ă  partir du contrĂŽleur de dĂ©ploiement. + +2. VĂ©rifiez si la restauration a rĂ©ussi et que le dĂ©ploiement s'exĂ©cute comme prĂ©vu, exĂ©cutez: + + ```shell + kubectl get deployment nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 30m + ``` + +3. Obtenez la description du dĂ©ploiement: + + ```shell + kubectl describe deployment nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + Name: nginx-deployment + Namespace: default + CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 + ``` + +## Mise Ă  l'Ă©chelle d'un dĂ©ploiement + +Vous pouvez mettre Ă  l'Ă©chelle un dĂ©ploiement Ă  l'aide de la commande suivante: + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` + +La sortie est similaire Ă  ceci: + +```text +deployment.apps/nginx-deployment scaled +``` + +En supposant que l'[horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) est activĂ© dans votre cluster, vous pouvez configurer une mise Ă  l'Ă©chelle automatique pour votre dĂ©ploiement et choisir le nombre minimum et maximum de pods que vous souhaitez exĂ©cuter en fonction de l'utilisation du processeur de vos pods existants. + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` + +La sortie est similaire Ă  ceci: + +```text +deployment.apps/nginx-deployment scaled +``` + +### Mise Ă  l'Ă©chelle proportionnelle + +Les dĂ©ploiements RollingUpdate prennent en charge l'exĂ©cution simultanĂ©e de plusieurs versions d'une application. +Lorsque vous ou un autoscaler mettez Ă  l'Ă©chelle un dĂ©ploiement RollingUpdate qui se trouve au milieu d'un dĂ©ploiement (en cours ou en pause), le contrĂŽleur de dĂ©ploiement Ă©quilibre les rĂ©plicas supplĂ©mentaires dans les ReplicaSets actifs existants (ReplicaSets avec pods) afin d'attĂ©nuer le risque. +Ceci est appelĂ© *mise Ă  l'Ă©chelle proportionnelle*. + +Par exemple, vous exĂ©cutez un dĂ©ploiement avec 10 rĂ©plicas, [maxSurge](#max-surge)=3, et [maxUnavailable](#max-unavailable)=2. + +* Assurez-vous que les 10 rĂ©plicas de votre dĂ©ploiement sont en cours d'exĂ©cution. + + ```shell + kubectl get deploy + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 10 10 10 10 50s + ``` + +* Vous effectuez une mise Ă  jour vers une nouvelle image qui s'avĂšre impossible Ă  rĂ©soudre depuis l'intĂ©rieur du cluster. + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment image updated + ``` + +* La mise Ă  jour de l'image dĂ©marre un nouveau dĂ©ploiement avec ReplicaSet `nginx-deployment-1989198191`, mais elle est bloquĂ©e en raison de l'exigence `maxUnavailable` que vous avez mentionnĂ©e ci-dessus. + DĂ©couvrez l'Ă©tat du dĂ©ploiement: + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 5 5 0 9s + nginx-deployment-618515232 8 8 8 1m + ``` + +* Ensuite, une nouvelle demande de mise Ă  l'Ă©chelle pour le dĂ©ploiement arrive. + La mise Ă  l'Ă©chelle automatique incrĂ©mente les rĂ©plicas de dĂ©ploiement Ă  15. + Le contrĂŽleur de dĂ©ploiement doit dĂ©cider oĂč ajouter ces 5 nouvelles rĂ©pliques. + Si vous n'utilisiez pas la mise Ă  l'Ă©chelle proportionnelle, les 5 seraient ajoutĂ©s dans le nouveau ReplicaSet. + Avec une mise Ă  l'Ă©chelle proportionnelle, vous rĂ©partissez les rĂ©pliques supplĂ©mentaires sur tous les ReplicaSets. + Des proportions plus importantes vont aux ReplicaSets avec le plus de rĂ©pliques et des proportions plus faibles vont aux ReplicaSets avec moins de replicas. + Tous les restes sont ajoutĂ©s au ReplicaSet avec le plus de rĂ©pliques. + Les ReplicaSets avec zĂ©ro rĂ©plicas ne sont pas mis Ă  l'Ă©chelle. + +Dans notre exemple ci-dessus, 3 rĂ©pliques sont ajoutĂ©es Ă  l'ancien ReplicaSet et 2 rĂ©pliques sont ajoutĂ©es au nouveau ReplicaSet. +Le processus de dĂ©ploiement devrait Ă©ventuellement dĂ©placer toutes les rĂ©pliques vers le nouveau ReplicaSet, en supposant que les nouvelles rĂ©pliques deviennent saines. +Pour confirmer cela, exĂ©cutez: + +```shell +kubectl get deploy +``` + +La sortie est similaire Ă  ceci: + +```text +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` + +Le statut de dĂ©ploiement confirme la façon dont les rĂ©plicas ont Ă©tĂ© ajoutĂ©s Ă  chaque ReplicaSet. + +```shell +kubectl get rs +``` + +La sortie est similaire Ă  ceci: + +```text +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## Pause et reprise d'un dĂ©ploiement + +Vous pouvez suspendre un dĂ©ploiement avant de dĂ©clencher une ou plusieurs mises Ă  jour, puis le reprendre. +Cela vous permet d'appliquer plusieurs correctifs entre la pause et la reprise sans dĂ©clencher de dĂ©ploiements inutiles. + +* Par exemple, avec un dĂ©ploiement qui vient d'ĂȘtre crĂ©Ă©: + Obtenez les dĂ©tails du dĂ©ploiement: + + ```shell + kubectl get deploy + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx 3 3 3 3 1m + ``` + + Obtenez le statut de dĂ©ploiement: + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 1m + ``` + +* Mettez le dĂ©ploiement en pause en exĂ©cutant la commande suivante: + + ```shell + kubectl rollout pause deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment paused + ``` + +* Mettez ensuite Ă  jour l'image du dĂ©ploiement: + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment image updated + ``` + +* Notez qu'aucun nouveau dĂ©ploiement n'a commencĂ©: + + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployments "nginx" + REVISION CHANGE-CAUSE + 1 + ``` + +* Obtenez l'Ă©tat de dĂ©ploiement pour vous assurer que le dĂ©ploiement est correctement mis Ă  jour: + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 2m + ``` + +* Vous pouvez effectuer autant de mises Ă  jour que vous le souhaitez, par exemple, mettre Ă  jour les ressources qui seront utilisĂ©es: + + ```shell + kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment resource requirements updated + ``` + + L'Ă©tat initial du dĂ©ploiement avant de le suspendre continuera de fonctionner, mais les nouvelles mises Ă  jour du dĂ©ploiement n'auront aucun effet tant que le dĂ©ploiement sera suspendu. + +* Finalement, reprenez le dĂ©ploiement et observez un nouveau ReplicaSet Ă  venir avec toutes les nouvelles mises Ă  jour: + + ```shell + kubectl rollout resume deployment.v1.apps/nginx-deployment + ``` + + La sortie est similaire Ă  ceci: + + ```text + deployment.apps/nginx-deployment resumed + ``` + +* Regardez l'Ă©tat du dĂ©ploiement jusqu'Ă  ce qu'il soit terminĂ©. + + ```shell + kubectl get rs -w + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-2142116321 2 2 2 2m + nginx-3926361531 2 2 0 6s + nginx-3926361531 2 2 1 18s + nginx-2142116321 1 2 2 2m + nginx-2142116321 1 2 2 2m + nginx-3926361531 3 2 1 18s + nginx-3926361531 3 2 1 18s + nginx-2142116321 1 1 1 2m + nginx-3926361531 3 3 1 18s + nginx-3926361531 3 3 2 19s + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 20s + ``` + +* Obtenez le statut du dernier dĂ©ploiement: + + ```shell + kubectl get rs + ``` + + La sortie est similaire Ă  ceci: + + ```text + NAME DESIRED CURRENT READY AGE + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 28s + ``` + +{{< note >}} +Vous ne pouvez pas annuler un dĂ©ploiement suspendu avant de le reprendre. +{{< /note >}} + +## Statut de dĂ©ploiement + +Un dĂ©ploiement entre dans diffĂ©rents Ă©tats au cours de son cycle de vie. +Il peut ĂȘtre [progressant](#progressing-deployment) lors du dĂ©ploiement d'un nouveau ReplicaSet, il peut ĂȘtre [effectuĂ©](#complete-deployment), ou il peut [ne pas progresser](#failed-deployment). + +### Progression du dĂ©ploiement + +Kubernetes marque un dĂ©ploiement comme _progressing_ lorsqu'une des tĂąches suivantes est effectuĂ©e: + +* Le dĂ©ploiement crĂ©e un nouveau ReplicaSet. +* Le dĂ©ploiement augmente son nouveau ReplicaSet. +* Le dĂ©ploiement rĂ©duit ses anciens ReplicaSet. +* De nouveaux pods deviennent prĂȘts ou disponibles (prĂȘt pour au moins [MinReadySeconds](#min-ready-seconds)). + +Vous pouvez surveiller la progression d'un dĂ©ploiement Ă  l'aide de `kubectl rollout status`. + +### DĂ©ploiement effectuĂ© + +Kubernetes marque un dĂ©ploiement comme _effectuĂ©_ lorsqu'il prĂ©sente les caractĂ©ristiques suivantes: + +* Toutes les rĂ©pliques associĂ©es au dĂ©ploiement ont Ă©tĂ© mises Ă  jour vers la derniĂšre version que vous avez spĂ©cifiĂ©e, ce qui signifie que toutes les mises Ă  jour que vous avez demandĂ©es ont Ă©tĂ© effectuĂ©es. +* Toutes les rĂ©pliques associĂ©es au dĂ©ploiement sont disponibles. +* Aucune ancienne rĂ©plique pour le dĂ©ploiement n'est en cours d'exĂ©cution. + +Vous pouvez vĂ©rifier si un dĂ©ploiement est terminĂ© en utilisant `kubectl rollout status`. +Si le dĂ©ploiement s'est terminĂ© avec succĂšs, `kubectl rollout status` renvoie un code de sortie de 0. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` + +La sortie est similaire Ă  ceci: + +```text +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### DĂ©ploiement Ă©chouĂ© + +Votre dĂ©ploiement peut rester bloquĂ© en essayant de dĂ©ployer son nouveau ReplicaSet sans jamais terminer. +Cela peut se produire en raison de certains des facteurs suivants: + +* Quota insuffisant +* Échecs de la sonde de prĂ©paration +* Erreurs d'extraction d'image +* Permissions insuffisantes +* Plages limites +* Mauvaise configuration de l'exĂ©cution de l'application + +Vous pouvez dĂ©tecter cette condition en spĂ©cifiant un paramĂštre d'Ă©chĂ©ance dans votre spĂ©cification de dĂ©ploiement: +([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). +`.spec.progressDeadlineSeconds` indique le nombre de secondes pendant lesquelles le contrĂŽleur de dĂ©ploiement attend avant d'indiquer (dans l'Ă©tat de dĂ©ploiement) que la progression du dĂ©ploiement est au point mort. + +La commande `kubectl` suivante dĂ©finit la spĂ©cification avec `progressDeadlineSeconds` pour que le contrĂŽleur signale l'absence de progression pour un dĂ©ploiement aprĂšs 10 minutes: + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` + +La sortie est similaire Ă  ceci: + +```text +deployment.apps/nginx-deployment patched +``` + +Une fois le dĂ©lai dĂ©passĂ©, le contrĂŽleur de dĂ©ploiement ajoute un `DeploymentCondition` avec les attributs suivants aux `.status.conditions` du dĂ©ploiement: + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +Voir les [conventions Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) pour plus d'informations sur les conditions d'Ă©tat. + +{{< note >}} +Kubernetes ne prend aucune mesure sur un dĂ©ploiement bloquĂ©, sauf pour signaler une condition d'Ă©tat avec `Reason=ProgressDeadlineExceeded`. +Les orchestrateurs de niveau supĂ©rieur peuvent en tirer parti et agir en consĂ©quence, par exemple, restaurer le dĂ©ploiement vers sa version prĂ©cĂ©dente. +{{< /note >}} + +{{< note >}} +Si vous suspendez un dĂ©ploiement, Kubernetes ne vĂ©rifie pas la progression par rapport Ă  votre Ă©chĂ©ance spĂ©cifiĂ©e. +Vous pouvez suspendre un dĂ©ploiement en toute sĂ©curitĂ© au milieu d'un dĂ©ploiement et reprendre sans dĂ©clencher la condition de dĂ©passement du dĂ©lai. +{{< /note >}} + +Vous pouvez rencontrer des erreurs transitoires avec vos dĂ©ploiements, soit en raison d'un dĂ©lai d'attente bas que vous avez dĂ©fini, soit en raison de tout autre type d'erreur pouvant ĂȘtre traitĂ© comme transitoire. +Par exemple, supposons que votre quota soit insuffisant. +Si vous dĂ©crivez le dĂ©ploiement, vous remarquerez la section suivante: + +```shell +kubectl describe deployment nginx-deployment +``` + +La sortie est similaire Ă  ceci: + +```text +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +Si vous exĂ©cutez `kubectl get deployment nginx-deployment -o yaml`, l'Ă©tat de dĂ©ploiement est similaire Ă  ceci: + +```yaml +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +Finalement, une fois la date limite de progression du dĂ©ploiement dĂ©passĂ©e, Kubernetes met Ă  jour le statut et la raison de la condition de progression: + +```text +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Vous pouvez rĂ©soudre un problĂšme de quota insuffisant en rĂ©duisant votre dĂ©ploiement, en rĂ©duisant d'autres contrĂŽleurs que vous exĂ©cutez ou en augmentant le quota de votre namespace. +Si vous remplissez les conditions de quota et que le contrĂŽleur de dĂ©ploiement termine ensuite le dĂ©ploiement de dĂ©ploiement, vous verrez la mise Ă  jour de l'Ă©tat du dĂ©ploiement avec une condition rĂ©ussie (`Status=True` et `Reason=NewReplicaSetAvailable`). + +```text +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Type=Available` avec `Status=True` signifie que votre dĂ©ploiement a une disponibilitĂ© minimale. +La disponibilitĂ© minimale est dictĂ©e par les paramĂštres spĂ©cifiĂ©s dans la stratĂ©gie de dĂ©ploiement. +`Type=Progressing` avec `Status=True` signifie que votre dĂ©ploiement est soit au milieu d'un dĂ©ploiement et qu'il progresse ou qu'il a terminĂ© avec succĂšs sa progression et que les nouvelles rĂ©pliques minimales requises sont disponibles (voir la raison de la condition pour les dĂ©tails - dans notre cas, `Reason=NewReplicaSetAvailable` signifie que le dĂ©ploiement est terminĂ©). + +Vous pouvez vĂ©rifier si un dĂ©ploiement n'a pas pu progresser en utilisant `kubectl rollout status`. +`kubectl rollout status` renvoie un code de sortie diffĂ©rent de zĂ©ro si le dĂ©ploiement a dĂ©passĂ© le dĂ©lai de progression. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` + +La sortie est similaire Ă  ceci: + +```text +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### Agir sur un dĂ©ploiement Ă©chouĂ© + +Toutes les actions qui s'appliquent Ă  un dĂ©ploiement complet s'appliquent Ă©galement Ă  un dĂ©ploiement ayant Ă©chouĂ©. +Vous pouvez le mettre Ă  l'Ă©chelle Ă  la hausse/baisse, revenir Ă  une rĂ©vision prĂ©cĂ©dente ou mĂȘme la suspendre si vous devez appliquer plusieurs rĂ©glages dans le modĂšle de pod de dĂ©ploiement. + +## Politique de nettoyage + +Vous pouvez dĂ©finir le champ `.spec.revisionHistoryLimit` dans un dĂ©ploiement pour spĂ©cifier le nombre d'anciens ReplicaSets pour ce dĂ©ploiement que vous souhaitez conserver. +Le reste sera effacĂ© en arriĂšre-plan. +Par dĂ©faut, c'est 10. + +{{< note >}} +La dĂ©finition explicite de ce champ sur 0 entraĂźnera le nettoyage de tout l'historique de votre dĂ©ploiement, de sorte que le dĂ©ploiement ne pourra pas revenir en arriĂšre. +{{< /note >}} + +## DĂ©ploiement des Canaries + +Si vous souhaitez dĂ©ployer des versions sur un sous-ensemble d'utilisateurs ou de serveurs Ă  l'aide du dĂ©ploiement, vous pouvez crĂ©er plusieurs dĂ©ploiements, un pour chaque version, en suivant le modĂšle canari dĂ©crit dans [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). + +## Écriture d'une spĂ©cification de dĂ©ploiement + +Comme pour toutes les autres configurations Kubernetes, un dĂ©ploiement a besoin des champs `apiVersion`, `kind` et `metadata`. +Pour des informations gĂ©nĂ©rales sur l'utilisation des fichiers de configuration, voir [dĂ©ploiement d'applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/), configuration des conteneurs, et [Utilisation de kubectl pour gĂ©rer les ressources](/docs/concepts/overview/working-with-objects/object-management/). + +Un dĂ©ploiement nĂ©cessite Ă©galement un [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Pod Template + +Les `.spec.template` et `.spec.selector` sont les seuls champs obligatoires du `.spec`. + +Le `.spec.template` est un [Pod template](/fr/docs/concepts/workloads/pods/pod-overview/#pod-templates). +Il a exactement le mĂȘme schĂ©ma qu'un [Pod](/fr/docs/concepts/workloads/pods/pod/), sauf qu'il est imbriquĂ© et n'a pas de `apiVersion` ou de `kind`. + +En plus des champs obligatoires pour un pod, un Pod Template dans un dĂ©ploiement doit spĂ©cifier des labels appropriĂ©es et une stratĂ©gie de redĂ©marrage appropriĂ©e. +Pour les labels, assurez-vous de ne pas chevaucher l'action d'autres contrĂŽleurs. +Voir [sĂ©lecteur](#selector)). + +Seulement un [`.spec.template.spec.restartPolicy`](/fr/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) Ă©gal Ă  `Always` est autorisĂ©, ce qui est la valeur par dĂ©faut s'il n'est pas spĂ©cifiĂ©. + +### RĂ©pliques + +`.spec.replicas` est un champ facultatif qui spĂ©cifie le nombre de pods souhaitĂ©s. +Il vaut par dĂ©faut 1. + +### SĂ©lecteur + +`.spec.selector` est un champ obligatoire qui spĂ©cifie un [sĂ©lecteur de labels](/docs/concepts/overview/working-with-objects/labels/) pour les pods ciblĂ©s par ce dĂ©ploiement. + +`.spec.selector` doit correspondre `.spec.template.metadata.labels`, ou il sera rejetĂ© par l'API. + +Dans la version d'API `apps/v1`, `.spec.selector` et `.metadata.labels` ne sont pas dĂ©finis par dĂ©faut sur `.spec.template.metadata.labels` s'ils ne sont pas dĂ©finis. +Ils doivent donc ĂȘtre dĂ©finis explicitement. +Notez Ă©galement que `.spec.selector` est immuable aprĂšs la crĂ©ation du dĂ©ploiement dans `apps/v1`. + +Un dĂ©ploiement peut mettre fin aux pods dont les Ă©tiquettes correspondent au sĂ©lecteur si leur modĂšle est diffĂ©rent de `.spec.template` ou si le nombre total de ces pods dĂ©passe `.spec.replicas`. +Il fait apparaĂźtre de nouveaux pods avec `.spec.template` si le nombre de pods est infĂ©rieur au nombre souhaitĂ©. + +{{< note >}} +Vous ne devez pas crĂ©er d'autres pods dont les labels correspondent Ă  ce sĂ©lecteur, soit directement, en crĂ©ant un autre dĂ©ploiement, soit en crĂ©ant un autre contrĂŽleur tel qu'un ReplicaSet ou un ReplicationController. +Si vous le faites, le premier dĂ©ploiement pense qu'il a crĂ©Ă© ces autres pods. +Kubernetes ne vous empĂȘche pas de le faire. +{{< /note >}} + +Si vous avez plusieurs contrĂŽleurs qui ont des sĂ©lecteurs qui se chevauchent, les contrĂŽleurs se battront entre eux et ne se comporteront pas correctement. + +### StratĂ©gie + +`.spec.strategy` spĂ©cifie la stratĂ©gie utilisĂ©e pour remplacer les anciens pods par de nouveaux. +`.spec.strategy.type` peut ĂȘtre "Recreate" ou "RollingUpdate". +"RollingUpdate" est la valeur par dĂ©faut. + +#### DĂ©ploiment Recreate + +Tous les pods existants sont tuĂ©s avant que de nouveaux ne soient crĂ©Ă©s lorsque `.spec.strategy.type==Recreate`. + +#### DĂ©ploiement de mise Ă  jour continue + +Le dĂ©ploiement met Ă  jour les pods dans une [mise Ă  jour continue](/docs/tasks/run-application/rolling-update-replication-controller/) quand `.spec.strategy.type==RollingUpdate`. +Vous pouvez spĂ©cifier `maxUnavailable` et `maxSurge` pour contrĂŽler le processus de mise Ă  jour continue. + +##### Max non disponible + +`.spec.strategy.rollingUpdate.maxUnavailable` est un champ facultatif qui spĂ©cifie le nombre maximal de pods qui peuvent ĂȘtre indisponibles pendant le processus de mise Ă  jour. +La valeur peut ĂȘtre un nombre absolu (par exemple, 5) ou un pourcentage des pods souhaitĂ©s (par exemple, 10%). +Le nombre absolu est calculĂ© Ă  partir du pourcentage en arrondissant vers le bas. +La valeur ne peut pas ĂȘtre 0 si `.spec.strategy.rollingUpdate.maxSurge` est 0. +La valeur par dĂ©faut est 25%. + +Par exemple, lorsque cette valeur est dĂ©finie sur 30%, l'ancien ReplicaSet peut ĂȘtre rĂ©duit Ă  70% des pods souhaitĂ©s immĂ©diatement au dĂ©marrage de la mise Ă  jour continue. +Une fois que les nouveaux pods sont prĂȘts, l'ancien ReplicaSet peut ĂȘtre rĂ©duit davantage, suivi d'une augmentation du nouveau ReplicaSet, garantissant que le nombre total de pods disponibles Ă  tout moment pendant la mise Ă  jour est d'au moins 70% des pods souhaitĂ©s. + +##### Max Surge + +`.spec.strategy.rollingUpdate.maxSurge` est un champ facultatif qui spĂ©cifie le nombre maximal de pods pouvant ĂȘtre crĂ©Ă©s sur le nombre de pods souhaitĂ©. +La valeur peut ĂȘtre un nombre absolu (par exemple, 5) ou un pourcentage des pods souhaitĂ©s (par exemple, 10%). +La valeur ne peut pas ĂȘtre 0 si `MaxUnavailable` est 0. +Le nombre absolu est calculĂ© Ă  partir du pourcentage en arrondissant. +La valeur par dĂ©faut est 25%. + +Par exemple, lorsque cette valeur est dĂ©finie sur 30%, le nouveau ReplicaSet peut ĂȘtre mis Ă  l'Ă©chelle immĂ©diatement au dĂ©marrage de la mise Ă  jour continue, de sorte que le nombre total d'anciens et de nouveaux pods ne dĂ©passe pas 130% des pods souhaitĂ©s. +Une fois que les anciens pods ont Ă©tĂ© dĂ©truits, le nouveau ReplicaSet peut ĂȘtre augmentĂ© davantage, garantissant que le nombre total de pods en cours d'exĂ©cution Ă  tout moment pendant la mise Ă  jour est au maximum de 130% des pods souhaitĂ©s. + +### Progress Deadline Seconds + +`.spec.progressDeadlineSeconds` est un champ facultatif qui spĂ©cifie le nombre de secondes pendant lesquelles vous souhaitez attendre que votre dĂ©ploiement progresse avant que le systĂšme ne signale que le dĂ©ploiement a [Ă©chouĂ©](#failed-deployment) - refait surface comme une condition avec `Type=Progressing`, `Status=False` et `Reason=ProgressDeadlineExceeded` dans l'Ă©tat de la ressource. +Le contrĂŽleur de dĂ©ploiement continuera de rĂ©essayer le dĂ©ploiement. +À l'avenir, une fois la restauration automatique implĂ©mentĂ©e, le contrĂŽleur de dĂ©ploiement annulera un dĂ©ploiement dĂšs qu'il observera une telle condition. + +S'il est spĂ©cifiĂ©, ce champ doit ĂȘtre supĂ©rieur Ă  `.spec.minReadySeconds`. + +### Min Ready Seconds + +`.spec.minReadySeconds` est un champ facultatif qui spĂ©cifie le nombre minimum de secondes pendant lequel un pod nouvellement crĂ©Ă© doit ĂȘtre prĂȘt sans qu'aucun de ses conteneurs ne plante, pour qu'il soit considĂ©rĂ© comme disponible. +Cette valeur par dĂ©faut est 0 (le pod sera considĂ©rĂ© comme disponible dĂšs qu'il sera prĂȘt). +Pour en savoir plus sur le moment oĂč un pod est considĂ©rĂ© comme prĂȘt, consultez [Sondes de conteneur](/fr/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Rollback To + +Le champ `.spec.rollbackTo` est obsolĂšte dans les versions d'API `extensions/v1beta1` et `apps/v1beta1` et n'est plus pris en charge dans les versions d'API commençant par `apps/v1beta2`. +Utilisez, `kubectl rollout undo` pour [Revenir Ă  une rĂ©vision prĂ©cĂ©dente](#revenir-Ă -une-rĂ©vision-prĂ©cĂ©dente). + +### Limite de l'historique des rĂ©visions + +L'historique de rĂ©vision d'un dĂ©ploiement est stockĂ© dans les ReplicaSets qu'il contrĂŽle. + +`.spec.revisionHistoryLimit` est un champ facultatif qui spĂ©cifie le nombre d'anciens ReplicaSets Ă  conserver pour permettre la restauration. +Ces anciens ReplicaSets consomment des ressources dans `etcd` et encombrent la sortie de `kubectl get rs`. +La configuration de chaque rĂ©vision de dĂ©ploiement est stockĂ©e dans ses ReplicaSets; par consĂ©quent, une fois un ancien ReplicaSet supprimĂ©, vous perdez la possibilitĂ© de revenir Ă  cette rĂ©vision du dĂ©ploiement. +Par dĂ©faut, 10 anciens ReplicaSets seront conservĂ©s, mais sa valeur idĂ©ale dĂ©pend de la frĂ©quence et de la stabilitĂ© des nouveaux dĂ©ploiements. + +Plus prĂ©cisĂ©ment, la dĂ©finition de ce champ Ă  zĂ©ro signifie que tous les anciens ReplicaSets avec 0 rĂ©plicas seront nettoyĂ©s. +Dans ce cas, un nouveau panneau dĂ©roulant DĂ©ploiement ne peut pas ĂȘtre annulĂ©, car son historique de rĂ©vision est nettoyĂ©. + +### Paused + +`.spec.paused` est un champ boolĂ©en facultatif pour suspendre et reprendre un dĂ©ploiement. +La seule diffĂ©rence entre un dĂ©ploiement suspendu et un autre qui n'est pas suspendu, c'est que toute modification apportĂ©e au `PodTemplateSpec` du dĂ©ploiement suspendu ne dĂ©clenchera pas de nouveaux dĂ©ploiements tant qu'il sera suspendu. +Un dĂ©ploiement n'est pas suspendu par dĂ©faut lors de sa crĂ©ation. + +## Alternative aux dĂ©ploiements + +### kubectl rolling-update + +[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) met Ă  jour les pods et les ReplicationControllers de la mĂȘme maniĂšre. +Mais les dĂ©ploiements sont recommandĂ©s, car ils sont dĂ©claratifs, cĂŽtĂ© serveur et ont des fonctionnalitĂ©s supplĂ©mentaires, telles que la restauration de toute rĂ©vision prĂ©cĂ©dente mĂȘme aprĂšs la mise Ă  jour progressive.. + +{{% /capture %}} diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md index fa36f6a9c0..d570b13bba 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md @@ -113,7 +113,7 @@ en cours d'exĂ©cution : `Failure`. Si le Conteneur ne fournit pas de readiness probe, l'Ă©tat par dĂ©faut est `Success`. -### Quand devez-vous uiliser une liveness ou une readiness probe ? +### Quand devez-vous utiliser une liveness ou une readiness probe ? Si le process de votre Conteneur est capable de crasher de lui-mĂȘme lorsqu'il rencontre un problĂšme ou devient inopĂ©rant, vous n'avez pas forcĂ©ment besoin diff --git a/content/fr/docs/contribute/advanced.md b/content/fr/docs/contribute/advanced.md new file mode 100644 index 0000000000..7cf7ad7cba --- /dev/null +++ b/content/fr/docs/contribute/advanced.md @@ -0,0 +1,94 @@ +--- +title: Contributions avancĂ©es +slug: advanced +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Cette page suppose que vous avez lu et maĂźtrisĂ© les sujets suivants : [Commencez Ă  contribuer](/docs/contribute/start/) et [Contribution IntermĂ©diaire](/docs/contribute/intermediate/) et ĂȘtes prĂȘts Ă  apprendre plus de façons de contribuer. +Vous devez utiliser Git et d'autres outils pour certaines de ces tĂąches. + +{{% /capture %}} + +{{% capture body %}} + +## Soyez le trieur de PR pendant une semaine + +Les [approbateurs SIG Docs](/docs/contribute/participating/#approvers) peuvent ĂȘtre trieurs de Pull Request (PR). + +Les approbateurs SIG Docs sont ajoutĂ©s au [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) pour les rotations hebdomadaires. +Les fonctions de trieur de PR incluent: + +- Faire une revue quotidienne des nouvelles pull requests. + - Aidez les nouveaux contributeurs Ă  signer le CLA et fermez toutes les PR oĂč le CLA n'a pas Ă©tĂ© signĂ© depuis deux semaines. + Les auteurs de PR peuvent rouvrir la PR aprĂšs avoir signĂ© le CLA, c’est donc un moyen Ă  faible risque de s’assurer que rien n’est merged sans un CLA signĂ©. + - Fournir des informations sur les modifications proposĂ©es, notamment en facilitant les examens techniques des membres d'autres SIGs. + - Faire un merge des PRs quand elles sont prĂȘtes, ou fermer celles qui ne devraient pas ĂȘtre acceptĂ©es. +- Triez et Ă©tiquetez les tickets entrants (Github Issues) chaque jour. + Consultez [Contributions IntermĂ©diaires](/docs/contribute/intermediate/) pour obtenir des instructions sur la maniĂšre dont SIG Docs utilise les mĂ©tadonnĂ©es. + +### RequĂȘtes Github utiles pour les trieurs + +Les requĂȘtes suivantes sont utiles lors des opĂ©rations de triage. +AprĂšs avoir utilisĂ© ces trois requĂȘtes, la liste restante de PRs devant ĂȘtre examinĂ©es est gĂ©nĂ©ralement petite. +Ces requĂȘtes excluent spĂ©cifiquement les PRs de localisation, et n'incluent que la branche `master` (sauf la derniere). + +- [Pas de CLA, non Ă©ligible au merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): + Rappelez au contributeur de signer le CLA. S’ils ont dĂ©jĂ  Ă©tĂ© rappelĂ©s Ă  la fois par le bot et par un humain, fermez la PR et rappelez-leur qu'ils peuvent l'ouvrir aprĂšs avoir signĂ© le CLA. + **Nous ne pouvons mĂȘme pas passer en revue les PR dont les auteurs n'ont pas signĂ© le CLA !** +- [A besoin de LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): + Si cela nĂ©cessite une rĂ©vision technique, contactez l'un des rĂ©viseurs proposĂ©s par le bot. + Si cela nĂ©cessite une rĂ©vision de la documentation ou une Ă©dition, vous pouvez soit suggĂ©rer des modifications, soit ajouter un commit d'Ă©dition Ă  la PR pour la faire avancer. +- [A des LGTM, a besoin de docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): + Voyez si vous pouvez comprendre ce qui doit se passer pour que la PR soit mergĂ©e. +- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): Si c'est basĂ© sur une branche `dev-`, c'est pour une release prochaine. + Assurez vous que le [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) est au courant. + Si elle se base sur une branche obsolĂšte, aidez l'auteur de la PR Ă  comprendre comment choisir la meilleure branche. + +## Proposer des amĂ©liorations + +Les [membres](/docs/contribute/participating/#members) SIG Docs peuvent proposer des amĂ©liorations. + +AprĂšs avoir contribuĂ© Ă  la documentation de Kubernetes pendant un certain temps, vous pouvez avoir des idĂ©es pour amĂ©liorer le guide de style, les outils utilisĂ©s pour construire la documentation, le style du site, les processus de rĂ©vision et faire un merge de pull requests, ou d'autres aspects de la documentation. +Pour une transparence maximale, ces types de propositions doivent ĂȘtre discutĂ©es lors d’une rĂ©union SIG Docs ou sur la [liste de diffusion kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +En outre, il peut ĂȘtre vraiment utile de situer le fonctionnement actuel et de dĂ©terminer les raisons pour lesquelles des dĂ©cisions antĂ©rieures ont Ă©tĂ© prises avant de proposer des changements radicaux. +Le moyen le plus rapide d’obtenir des rĂ©ponses aux questions sur le fonctionnement actuel de la documentation est de le demander dans le canal `#sig-docs` sur le Slack officiel [kubernetes.slack.com](https://kubernetes.slack.com) + +Une fois que la discussion a eu lieu et que le SIG est d'accord sur le rĂ©sultat souhaitĂ©, vous pouvez travailler sur les modifications proposĂ©es de la maniĂšre la plus appropriĂ©e. +Par exemple, une mise Ă  jour du guide de style ou du fonctionnement du site Web peut impliquer l’ouverture d’une pull request, une modification liĂ©e aux tests de documentation peut impliquer de travailler avec sig-testing. + +## Coordonner la documentation pour une version de Kubernetes + +[Les approbateurs](/docs/contribute/participating/#approvers) SIG Docs peuvent coordonner les tĂąches liĂ©es Ă  la documentation pour une release de Kubernetes. + +Chaque release de Kubernetes est coordonnĂ©e par une Ă©quipe de personnes participant au sig-release Special Interest Group (SIG). +Les autres membres de l'Ă©quipe de publication pour une release donnĂ©e incluent un responsable gĂ©nĂ©ral de la publication, ainsi que des reprĂ©sentants de sig-pm, de sig-testing et d'autres. +Pour en savoir plus sur les processus de release de Kubernetes, reportez-vous Ă  la section [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). + +Le reprĂ©sentant de SIG Docs pour une release donnĂ©e coordonne les tĂąches suivantes: + +- Surveillez le feature-tracking spreadsheet pour les fonctionnalitĂ©s nouvelles ou modifiĂ©es ayant un impact sur la documentation. + Si la documentation pour une fonctionnalitĂ© donnĂ©e ne sera pas prĂȘte pour la release, la fonctionnalitĂ© peut ne pas ĂȘtre autorisĂ©e Ă  entrer dans la release. +- Assistez rĂ©guliĂšrement aux rĂ©unions de sig-release et donnez des mises Ă  jour sur l'Ă©tat de la documentation pour la release. +- Consultez et copiez la documentation de la fonctionnalitĂ© rĂ©digĂ©e par le SIG responsable de la mise en Ɠuvre de la fonctionnalitĂ©. +- Mergez les pull requests liĂ©es Ă  la release et maintenir la branche de fonctionnalitĂ© Git pour la version. +- Encadrez d'autres contributeurs SIG Docs qui souhaitent apprendre Ă  jouer ce rĂŽle Ă  l'avenir. +  Ceci est connu comme "l'observation" (shadowing en anglais). +- Publiez les modifications de la documentation relatives Ă  la version lorsque les artefacts de la version sont publiĂ©s. + +La coordination d'une publication est gĂ©nĂ©ralement un engagement de 3 Ă  4 mois et les tĂąches sont alternĂ©es entre les approbateurs SIG Docs. + +## Parrainez un nouveau contributeur + +Les [relecteurs](/docs/contribute/participating/#reviewers) SIG Docs peuvent parrainer de nouveaux contributeurs. + +AprĂšs que les nouveaux contributeurs aient soumis avec succĂšs 5 pull requests significatives vers un ou plusieurs dĂ©pĂŽts Kubernetes, ils/elles sont Ă©ligibles pour postuler Ă  l'[adhĂ©sion](/docs/contribute/participating#members) dans l'organisation Kubernetes. +L'adhĂ©sion des contributeurs doit ĂȘtre soutenue par deux sponsors qui sont dĂ©jĂ  des rĂ©viseurs. + +Les nouveaux contributeurs docs peuvent demander des sponsors dans le canal #sig-docs sur le [Slack Kubernetes](https://kubernetes.slack.com) ou sur la [mailing list SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +Si vous vous sentez confiant dans le travail des candidats, vous vous portez volontaire pour les parrainer. +Lorsqu’ils soumettent leur demande d’adhĂ©sion, rĂ©pondez-y avec un "+1" et indiquez les raisons pour lesquelles vous estimez que les demandeurs sont des candidat(e)s valables pour devenir membre de l’organisation Kubernetes. + +{{% /capture %}} diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 4d9ef1a3fc..d1a521c69d 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -462,13 +462,13 @@ Celles-ci ne sont pas configurables pour le moment et diffĂšrent selon le pilote Le partage de dossier hĂŽte n'est pas encore implĂ©mentĂ© dans le pilote KVM. {{< /note >}} -| Pilote | OS | HostFolder | VM | -|---------------|---------|------------|-----------| -| VirtualBox | Linux | /home | /hosthome | -| VirtualBox | macOS | /Users | /Users | -| VirtualBox | Windows | C://Users | /c/Users | -| VMware Fusion | macOS | /Users | /Users | -| Xhyve | macOS | /Users | /Users | +| Pilote | OS | HostFolder | VM | +|---------------|---------|-------------|-------------| +| VirtualBox | Linux | ``/home`` |``/hosthome``| +| VirtualBox | macOS | ``/Users`` |``/Users`` | +| VirtualBox | Windows | ``C:/Users``|``/c/Users`` | +| VMware Fusion | macOS | ``/Users`` |``/Users`` | +| Xhyve | macOS | ``/Users`` |``/Users`` | ## Registres de conteneurs privĂ©s diff --git a/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md new file mode 100644 index 0000000000..f40e6c4fa3 --- /dev/null +++ b/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -0,0 +1,221 @@ +--- +title: Tableau de bord (Dashboard) +content_template: templates/concept +weight: 10 +card: + name: tasks + weight: 30 + title: Utiliser le tableau de bord (Dashboard) +--- + +{{% capture overview %}} + +Le tableau de bord (Dashboard) est une interface web pour Kubernetes. +Vous pouvez utiliser ce tableau de bord pour dĂ©ployer des applications conteneurisĂ©es dans un cluster Kubernetes, dĂ©panner votre application conteneurisĂ©e et gĂ©rer les ressources du cluster. +Vous pouvez utiliser le tableau de bord pour obtenir une vue d'ensemble des applications en cours d'exĂ©cution dans votre cluster, ainsi que pour crĂ©er ou modifier des ressources Kubernetes individuelles. (comme des Deployments, Jobs, DaemonSets, etc). +Par exemple, vous pouvez redimensionner un Deployment, lancer une mise Ă  jour progressive, recrĂ©er un pod ou dĂ©ployez de nouvelles applications Ă  l'aide d'un assistant de dĂ©ploiement. + +Le tableau de bord fournit Ă©galement des informations sur l'Ă©tat des ressources Kubernetes de votre cluster et sur les erreurs Ă©ventuelles. + +![Tableau de bord Kubernetes](/images/docs/ui-dashboard.png) + +{{% /capture %}} + +{{% capture body %}} + +## DĂ©ploiement du tableau de bord + +L'interface utilisateur du tableau de bord n'est pas dĂ©ployĂ©e par dĂ©faut. +Pour le dĂ©ployer, exĂ©cutez la commande suivante: + +```text +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended.yaml +``` + +## AccĂšs Ă  l'interface utilisateur du tableau de bord + +Pour protĂ©ger vos donnĂ©es dans le cluster, le tableau de bord se dĂ©ploie avec une configuration RBAC minimale par dĂ©faut. +Actuellement, le tableau de bord prend uniquement en charge la connexion avec un jeton de support. +Pour crĂ©er un jeton pour cette dĂ©mo, vous pouvez suivre notre guide sur [crĂ©er un exemple d'utilisateur](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md). + +{{< warning >}} +L’exemple d’utilisateur crĂ©Ă© dans le didacticiel disposera de privilĂšges d’administrateur et servira uniquement Ă  des fins pĂ©dagogiques. +{{< /warning >}} + +### Proxy en ligne de commande + +Vous pouvez accĂ©der au tableau de bord Ă  l'aide de l'outil en ligne de commande kubectl en exĂ©cutant la commande suivante: + +```text +kubectl proxy +``` + +Kubectl mettra le tableau de bord Ă  disposition Ă  l'adresse suivante: . + +Vous ne pouvez accĂ©der Ă  l'interface utilisateur _que_ depuis la machine sur laquelle la commande est exĂ©cutĂ©e. +Voir `kubectl proxy --help` pour plus d'options. + +{{< note >}} +La mĂ©thode d'authentification Kubeconfig ne prend pas en charge les fournisseurs d'identitĂ© externes ni l'authentification basĂ©e sur un certificat x509. +{{< /note >}} + +## Page de bienvenue + +Lorsque vous accĂ©dez au tableau de bord sur un cluster vide, la page d'accueil s'affiche. +Cette page contient un lien vers ce document ainsi qu'un bouton pour dĂ©ployer votre premiĂšre application. +De plus, vous pouvez voir quelles applications systĂšme sont exĂ©cutĂ©es par dĂ©faut dans le [namespace](/docs/tasks/administer-cluster/namespaces/) `kubernetes-dashboard` de votre cluster, par exemple le tableau de bord lui-mĂȘme. + +![Page d'accueil du tableau de bord Kubernetes](/images/docs/ui-dashboard-zerostate.png) + +## DĂ©ploiement d'applications conteneurisĂ©es + +Le tableau de bord vous permet de crĂ©er et de dĂ©ployer une application conteneurisĂ©e en tant que Deployment et optionnellement un Service avec un simple assistant. +Vous pouvez spĂ©cifier manuellement les dĂ©tails de l'application ou charger un fichier YAML ou JSON contenant la configuration de l'application. + +Cliquez sur le bouton **CREATE** dans le coin supĂ©rieur droit de n’importe quelle page pour commencer. + +### SpĂ©cifier les dĂ©tails de l'application + +L'assistant de dĂ©ploiement s'attend Ă  ce que vous fournissiez les informations suivantes: + +- **App name** (obligatoire): Nom de votre application. + Un [label](/docs/concepts/overview/working-with-objects/labels/) avec le nom sera ajoutĂ© au Deployment et Service, le cas Ă©chĂ©ant, qui sera dĂ©ployĂ©. + + Le nom de l'application doit ĂȘtre unique dans son [namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes. + Il doit commencer par une lettre minuscule et se terminer par une lettre minuscule ou un chiffre et ne contenir que des lettres minuscules, des chiffres et des tirets (-). + Il est limitĂ© Ă  24 caractĂšres. + Les espaces de dĂ©but et de fin sont ignorĂ©s. + +- **Container image** (obligatoire): L'URL d'une [image de conteneur](/docs/concepts/containers/images/) sur n'importe quel registre, ou une image privĂ©e (gĂ©nĂ©ralement hĂ©bergĂ©e sur le registre de conteneurs Google ou le hub Docker). + La spĂ©cification d'image de conteneur doit se terminer par un deux-points. + +- **Number of pods** (obligatoire): Nombre cible de pods dans lesquels vous souhaitez dĂ©ployer votre application. + La valeur doit ĂȘtre un entier positif. + + Un objet [Deployment](/docs/concepts/workloads/controllers/deployment/) sera crĂ©Ă© pour maintenir le nombre souhaitĂ© de pods dans votre cluster. + +- **Service** (optionnel): Pour certaines parties de votre application (par exemple les serveurs frontaux), vous souhaiterez peut-ĂȘtre exposer un [Service](/docs/concepts/services-networking/service/) sur une adresse IP externe, peut-ĂȘtre publique, en dehors de votre cluster (Service externe). + Pour les Services externes, vous devrez peut-ĂȘtre ouvrir un ou plusieurs ports pour le faire. + Trouvez plus de dĂ©tails [ici](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). + + Les autres services visibles uniquement de l'intĂ©rieur du cluster sont appelĂ©s Services internes. + + Quel que soit le type de service, si vous choisissez de crĂ©er un service et que votre conteneur Ă©coute sur un port (entrant), vous devez spĂ©cifier deux ports. + Le Service sera crĂ©Ă© en mappant le port (entrant) sur le port cible vu par le conteneur. + Ce Service acheminera le trafic vers vos pods dĂ©ployĂ©s. + Les protocoles pris en charge sont TCP et UDP. + Le nom DNS interne de ce service sera la valeur que vous avez spĂ©cifiĂ©e comme nom d'application ci-dessus. + +Si nĂ©cessaire, vous pouvez dĂ©velopper la section **Options avancĂ©es** dans laquelle vous pouvez spĂ©cifier davantage de paramĂštres: + +- **Description**: Le texte que vous entrez ici sera ajoutĂ© en tant qu'[annotation](/docs/concepts/overview/working-with-objects/annotations/) au Deployment et affichĂ© dans les dĂ©tails de l'application. + +- **Labels**: Les [labels](/docs/concepts/overview/working-with-objects/labels/) par dĂ©faut Ă  utiliser pour votre application sont le nom et la version de l’application. + Vous pouvez spĂ©cifier des labels supplĂ©mentaires Ă  appliquer au Deployment, Service (le cas Ă©chĂ©ant), et Pods, tels que la release, l'environnement, le niveau, la partition et la piste d'Ă©dition. + + Exemple: + + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` + +- **Namespace**: Kubernetes prend en charge plusieurs clusters virtuels s'exĂ©cutant sur le mĂȘme cluster physique. + Ces clusters virtuels sont appelĂ©s [namespaces](/docs/tasks/administer-cluster/namespaces/). + Ils vous permettent de partitionner les ressources en groupes nommĂ©s de maniĂšre logique. + + Le tableau de bord propose tous les namespaces disponibles dans une liste dĂ©roulante et vous permet de crĂ©er un nouveau namespace. + Le nom du namespace peut contenir au maximum 63 caractĂšres alphanumĂ©riques et des tirets (-), mais ne peut pas contenir de lettres majuscules. + Les noms de Namespace ne devraient pas ĂȘtre composĂ©s uniquement de chiffres. + Si le nom est dĂ©fini sous la forme d’un nombre, tel que 10, le pod sera placĂ© dans le namespace par dĂ©faut. + + Si la crĂ©ation du namespace rĂ©ussit, celle-ci est sĂ©lectionnĂ©e par dĂ©faut. + Si la crĂ©ation Ă©choue, le premier namespace est sĂ©lectionnĂ©. + +- **Image Pull Secret**: Si l'image de conteneur spĂ©cifiĂ©e est privĂ©e, il peut ĂȘtre nĂ©cessaire de configurer des identifiants de [pull secret](/docs/concepts/configuration/secret/). + + Le tableau de bord propose tous les secrets disponibles dans une liste dĂ©roulante et vous permet de crĂ©er un nouveau secret. + Le nom de secret doit respecter la syntaxe du nom de domaine DNS, par exemple. `new.image-pull.secret`. + Le contenu d'un secret doit ĂȘtre codĂ© en base64 et spĂ©cifiĂ© dans un fichier [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). + Le nom du secret peut contenir 253 caractĂšres maximum. + + Si la crĂ©ation du secret d’extraction d’image est rĂ©ussie, celle-ci est sĂ©lectionnĂ©e par dĂ©faut. + Si la crĂ©ation Ă©choue, aucun secret n'est appliquĂ©. + +- **CPU requirement (cores)** et **Memory requirement (MiB)**: Vous pouvez spĂ©cifier les [limites de ressource](/docs/tasks/configure-pod-container/limit-range/) minimales pour le conteneur. + Par dĂ©faut, les pods fonctionnent avec des limites de CPU et de mĂ©moire illimitĂ©es. + +- **Run command** et **Run command arguments**: Par dĂ©faut, vos conteneurs exĂ©cutent les valeurs par dĂ©faut de la [commande d'entrĂ©e](/docs/user-guide/containers/#containers-and-commands) de l'image spĂ©cifiĂ©e. + Vous pouvez utiliser les options de commande et les arguments pour remplacer la valeur par dĂ©faut. + +- **Run as privileged**: Ce paramĂštre dĂ©termine si les processus dans [conteneurs privilĂ©giĂ©s](/docs/user-guide/pods/#privileged-mode-for-pod-containers) sont Ă©quivalents aux processus s'exĂ©cutant en tant que root sur l'hĂŽte. + Les conteneurs privilĂ©giĂ©s peuvent utiliser des fonctionnalitĂ©s telles que la manipulation de la pile rĂ©seau et l'accĂšs aux pĂ©riphĂ©riques. + +- **Environment variables**: Kubernetes expose ses Services via des [variables d'environnement](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). + Vous pouvez composer une variable d'environnement ou transmettre des arguments Ă  vos commandes en utilisant les valeurs des variables d'environnement. + Ils peuvent ĂȘtre utilisĂ©s dans les applications pour trouver un Service. + Les valeurs peuvent rĂ©fĂ©rencer d'autres variables Ă  l'aide de la syntaxe `$(VAR_NAME)`. + +### TĂ©lĂ©chargement d'un fichier YAML ou JSON + +Kubernetes supporte la configuration dĂ©clarative. +Dans ce style, toute la configuration est stockĂ©e dans des fichiers de configuration YAML ou JSON Ă  l'aide des schĂ©mas de ressources de l'[API](/docs/concepts/overview/kubernetes-api/) de Kubernetes. + +Au lieu de spĂ©cifier les dĂ©tails de l'application dans l'assistant de dĂ©ploiement, vous pouvez dĂ©finir votre application dans des fichiers YAML ou JSON et tĂ©lĂ©charger les fichiers Ă  l'aide du tableau de bord. + +## Utilisation du tableau de bord + +Les sections suivantes dĂ©crivent des vues du tableau de bord de Kubernetes; ce qu'elles fournissent et comment peuvent-elles ĂȘtre utilisĂ©es. + +### Navigation + +Lorsque des objets Kubernetes sont dĂ©finis dans le cluster, le tableau de bord les affiche dans la vue initiale. +Par dĂ©faut, seuls les objets du namespace _default_ sont affichĂ©s, ce qui peut ĂȘtre modifiĂ© Ă  l'aide du sĂ©lecteur d'espace de nom situĂ© dans le menu de navigation. + +Le tableau de bord montre la plupart des types d'objets Kubernetes et les regroupe dans quelques catĂ©gories de menus. + +#### Vue d'ensemble de l'administrateur + +Pour les administrateurs de cluster et de namespace, le tableau de bord rĂ©pertorie les noeuds, les namespaces et les volumes persistants et propose des vues de dĂ©tail pour ceux-ci. +La vue Liste de nƓuds contient les mesures d'utilisation de CPU et de la mĂ©moire agrĂ©gĂ©es sur tous les nƓuds. +La vue dĂ©taillĂ©e affiche les mĂ©triques d'un nƓud, ses spĂ©cifications, son statut, les ressources allouĂ©es, les Ă©vĂ©nements et les pods s'exĂ©cutant sur le nƓud. + +#### Charges de travail + +Affiche toutes les applications en cours d'exĂ©cution dans le namespace selectionnĂ©. +La vue rĂ©pertorie les applications par type de charge de travail. (e.g., Deployments, Replica Sets, Stateful Sets, etc.) et chaque type de charge de travail peut ĂȘtre visualisĂ© sĂ©parĂ©ment. +Les listes rĂ©capitulent les informations exploitables sur les charges de travail, telles que le nombre de Pods prĂȘts pour un Replica Set ou l'utilisation actuelle de la mĂ©moire pour un Pod. + +Les vues dĂ©taillĂ©es des charges de travail affichent des informations sur l'Ă©tat et les spĂ©cifications, ainsi que les relations de surface entre les objets. +Par exemple, les Pods qu'un Replica Set controle ou bien les nouveaux Replica Sets et Horizontal Pod Autoscalers pour les Deployments. + +#### Services + +Affiche les ressources Kubernetes permettant d’exposer les services au monde externe et de les dĂ©couvrir au sein d’un cluster. +Pour cette raison, les vues Service et Ingress montrent les Pods ciblĂ©s par eux, les points de terminaison internes pour les connexions au cluster et les points de terminaison externes pour les utilisateurs externes. + +#### Stockage + +La vue de stockage montre les ressources Persistent Volume Claim qui sont utilisĂ©es par les applications pour stocker des donnĂ©es. + +#### Config Maps et Secrets + +Affiche toutes les ressources Kubernetes utilisĂ©es pour la configuration en temps rĂ©el d'applications s'exĂ©cutant dans des clusters. +La vue permet d’éditer et de gĂ©rer des objets de configuration et d’afficher les secrets cachĂ©s par dĂ©faut. + +#### Visualisation de journaux + +Les listes de Pod et les pages de dĂ©tail renvoient Ă  une visionneuse de journaux intĂ©grĂ©e au tableau de bord. +Le visualiseur permet d’exploiter les logs des conteneurs appartenant Ă  un seul Pod. + +![Visualisation de journaux](/images/docs/ui-dashboard-logs-view.png) + +{{% /capture %}} + +{{% capture whatsnext %}} + +Pour plus d'informations, voir la page du projet [Kubernetes Dashboard](https://github.com/kubernetes/dashboard). + +{{% /capture %}} diff --git a/content/fr/examples/controllers/nginx-deployment.yaml b/content/fr/examples/controllers/nginx-deployment.yaml new file mode 100644 index 0000000000..f7f95deebb --- /dev/null +++ b/content/fr/examples/controllers/nginx-deployment.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/id/community/_index.html b/content/id/community/_index.html new file mode 100644 index 0000000000..c37f67c000 --- /dev/null +++ b/content/id/community/_index.html @@ -0,0 +1,236 @@ +--- +title: Komunitas +layout: basic +cid: community +--- + +
+
+ Kubernetes Conference Gallery + Kubernetes Conference Gallery +
+ +
+
+

Komunitas Kubernetes -- pengguna, kontributor, dan budaya yang telah kami bangun bersama -- merupakan salah satu alasan terbesar yang menjadikan proyek open source ini melejit. Nilai dan budaya kami terus tumbuh dan berkembang seiring dengan pertumbuhan dan perkembangan proyek ini sendiri. Kami bekerja bersama untuk terus menyempurnakan proyek dan proses di dalamnya. +

Kami adalah orang-orang yang membantu menemukan masalah dan pull request, mengikuti pertemuan SIG, Kubernetes meetups, dan KubeCon, serta menyerukan untuk adopsi dan inovasinya, menjalankan kubectl get pods, serta berkontribusi pada ribuan area penting lainnya. Baca tentang bagaimana cara agar kamu dapat terlibat dan menjadi bagian dari komunitas hebat ini.

+
+
+ +
+ +Kode Etik      +Video      +Dikusi      +Acara dan Pertemuan      +Berita + +
+

+
+
+
+ Kubernetes Conference Gallery +
+ +
+ Kubernetes Conference Gallery +
+ +
+ Kubernetes Conference Gallery +
+ Kubernetes Conference Gallery + + +
+ + + +
+
+

+

+

Kode Etik Komunitas

+Komunitas Kubernetes menghargai penghormatan dan inklusivitas, dan menerapkan Kode Etik pada semua interaksi. Jika kamu menemukan pelanggaran Kode Etik pada suatu acara atau pertemuan, di Slack, atau pada mekanisme komunikasi lainnya, silakan hubungi conduct@kubernetes.io. Semua laporan dijamin kerahasiaannya. Kamu dapat membaca tentang komite di sini. +
+ +

+ + +BACA LEBIH LANJUT + + +
+
+
+ + + +
+

+

+

Video

+ +
Kami hadir di YouTube, sering malah. Pastikan kamu berlangganan untuk mendapatkan beragam topik menarik.
+ +
+ +
+ + + + +
+Tonton office hour bulanan ▶
+ +
+ +
+ + +
+Tonton rapat komunitas mingguan ▶ +
+ +
+ +
+ + + + +
+Tonton obrolan seru dari anggota komunitas ▶ +
+ + + +
+
+
+ + +
+

+

+

Diskusi

+ +
Kami sangat sering berdiskusi. Temukan kami dan bergabung dalam obrolan dan diskusi pada beragam platform.
+ +
+ +
+Forum" + +forum ▶ + +
+Diskusi berdasarkan topik teknis yang menjembatani dokumentasi, StackOverflow, dan banyak hal lainnya +
+
+ +
+Twitter + +twitter ▶ + +
Pengumuman langsung dari postingan blog, acara, berita, ide-ide menarik +
+
+ +
+GitHub + +github ▶ + +
+Semua hal tentang project tracking dan isu, dan tentu saja kode +
+
+ +
+Stack Overflow + +stack overflow ▶ + +
+ Pemecahan masalah teknis untuk masalah  apa saja + +
+
+ + + +
+
+
+

+

+
+

Acara Mendatang

+ {{< upcoming-events >}} +
+
+ +
+
+
+

Komunitas Global

+Terdapat lebih dari 150 meetups di seluruh dunia dan terus bertumbuh, temukan kube people terdekat. Jika belum ada di dekat kamu, ambil inisiatif dan buat komunitasmu. +
+ +
+TEMUKAN MEETUP +
+ + +
+
+ + + + +
+

+

+

Berita Terkini

+ +
+
+ +
+ +
+



+
+ +
diff --git a/content/id/community/code-of-conduct.md b/content/id/community/code-of-conduct.md new file mode 100644 index 0000000000..05e778acc4 --- /dev/null +++ b/content/id/community/code-of-conduct.md @@ -0,0 +1,24 @@ +--- +title: Komunitas +layout: basic +cid: community +css: /css/community.css +--- + +
+

Kode Etik Komunitas Kubernetes

+ +Kubernetes mengikuti +Kode Etik CNCF. +Teks dari CoC CNCF yang direplikasi di bawah ini berdasarkan commit 214585e. +Jika kamu menemukan halaman ini kedaluarsa, mohon +laporkan masalah ini. + +Jika kamu menemukan pelanggaran terhadap Kode Etik pada suatu acara atau pertemuan, di Slack, atau mekanisme komunikasi lainnya, silakan hubungi Komite Kode Etik Kubernetes. +Kamu dapat menghubungi kami melalui email di conduct@kubernetes.io. +Anonimitas kamu akan dilindungi. + +
+{{< include "/static/cncf-code-of-conduct.md" >}} +
+
diff --git a/content/id/community/static/cncf-code-of-conduct.md b/content/id/community/static/cncf-code-of-conduct.md new file mode 100644 index 0000000000..7ee127a6b3 --- /dev/null +++ b/content/id/community/static/cncf-code-of-conduct.md @@ -0,0 +1,31 @@ +Pedoman Perilaku Komunitas CNCF V1.0 +------------------------------------ + +### Kode Etik Kontributor + +Sebagai kontributor dan pengelola proyek ini, dan untuk kepentingan pembinaan sebuah komunitas yang terbuka dan ramah, kami berjanji untuk menghormati semua orang yang berkontribusi melalui masalah pelaporan, memposting permintaan fitur, memperbarui dokumentasi, mengajukan permintaan atau tambalan, dan kegiatan lainnya. + +Kami berkomitmen untuk menjadikan partisipasi dalam proyek ini pengalaman yang bebas dari pelecehan semua orang, terlepas dari tingkat pengalaman, jenis kelamin, identitas dan ekspresi gender, orientasi seksual, disabilitas, penampilan pribadi, ukuran tubuh, ras, etnis, usia, agama, atau kebangsaan. + +Contoh perilaku yang tidak dapat diterima oleh peserta termasuk di antaranya: + +- Penggunaan bahasa atau citra seksual +- Penyerangan pribadi +- Trolling atau komentar yang menghina/merendahkan +- Pelecehan secara publik atau pribadi +- Mempublikasikan informasi pribadi orang lain, seperti alamat fisik atau elektronik, tanpa izin tegas +- Perilaku tidak etis atau tidak profesional lainnya. + +Pengelola proyek memiliki hak dan tanggung jawab untuk menghapus, mengedit, atau menolak komentar, komit, kode, suntingan wiki, isu, dan kontribusi lain yang tidak selaras dengan Kode Etik ini. Dengan mengadopsi Kode Etik ini, pengelola proyek berkomitmen untuk menerapkan prinsip-prinsip ini secara adil dan konsisten pada setiap aspek pengelolaan proyek ini. Pengelola proyek yang tidak mengikuti atau menegakkan Kode Etik dapat dihapus secara permanen dari tim proyek. + +Kode etik ini berlaku baik di dalam ruang proyek maupun di ruang publik ketika seorang individu mewakili proyek atau komunitasnya. + +Contoh perilaku kasar, melecehkan, atau tidak dapat diterima di Kubernetes dapat dilaporkan dengan menghubungi [Komite Kode Etik Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) melalui . Untuk proyek lain, silakan hubungi pengelola proyek CNCF atau mediator kami, Mishi Choudhary . + +Kode Etik ini diadaptasi dari Covenant Contributor +, versi 1.2.0, tersedia di + + +### Pedoman Perilaku Acara CNCF + +Acara CNCF ini diatur oleh [Kode Etik](https://events.linuxfoundation.org/code-of-conduct/) Linux Foundation yang tersedia di halaman acara. Ini dirancang agar kompatibel dengan kebijakan di atas dan juga mencakup rincian lebih lanjut tentang hal menanggapi insiden. \ No newline at end of file diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md new file mode 100644 index 0000000000..61212e571d --- /dev/null +++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md @@ -0,0 +1,631 @@ +--- +title: Mengatur Sumber Daya Komputasi untuk Container +content_template: templates/concept +weight: 20 +feature: + title: Bin Packing Otomatis + description: > + Menaruh kontainer-kontainer secara otomatis berdasarkan kebutuhan sumber daya mereka dan batasan-batasan lainnya, tanpa mengorbankan ketersediaan. Membaurkan beban-beban kerja kritis dan _best-effort_ untuk meningkatkan penggunaan sumber daya dan menghemat lebih banyak sumber daya. +--- + +{{% capture overview %}} + +Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu +dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan +oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya, +scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih +untuk menaruh Pod-Pod. Dan saat limit (batas) sumber daya Container-Container telah ditentukan, +maka kemungkinan rebutan sumber daya pada sebuah Node dapat dihindari. +Untuk informasi lebih lanjut mengenai perbedaan `request` dan `limit`, lihat [QoS Sumber Daya](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md). + +{{% /capture %}} + +{{% capture body %}} + +## Jenis-jenis sumber daya + +_CPU_ dan _memori_ masing-masing merupakan _jenis sumber daya_ (_resource type_). +Sebuah jenis sumber daya memiliki satuan dasar. CPU ditentukan dalam satuan jumlah _core_, +dan memori ditentukan dalam satuan _bytes_. Jika kamu menggunakan Kubernetes v1.14 keatas, +kamu dapat menentukan sumber daya _huge page_. _Huge page_ adalah fitur khusus Linux +di mana kernel Node mengalokasikan blok-blok memori yang jauh lebih besar daripada ukuran +_page_ bawaannya. + +Sebagai contoh, pada sebuah sistem di mana ukuran _page_ bawaannya adalah 4KiB, kamu +dapat menentukan sebuah limit, `hugepages-2Mi: 80Mi`. Jika kontainer mencoba mengalokasikan +lebih dari 40 _huge page_ berukuran 20MiB (total 80MiB), maka alokasi tersebut akan gagal. + +{{< note >}} +Kamu tidak dapat melakukan _overcommit_ terhadap sumber daya `hugepages-*`. +Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_). +{{< /note >}} + +CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup +_sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan, +dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/). +Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah +objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server. + +## Request dan Limit Sumber daya dari Pod dan Container + +Setiap Container dari sebuah Pod dapat menentukan satu atau lebih dari hal-hal berikut: + +* `spec.containers[].resources.limits.cpu` +* `spec.containers[].resources.limits.memory` +* `spec.containers[].resources.limits.hugepages-` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` +* `spec.containers[].resources.requests.hugepages-` + +Walaupun `requests` dan `limits` hanya dapat ditentukan pada Container individual, akan +lebih mudah untuk membahas tentang request dan limit sumber daya dari Pod. Sebuah +_request/limit sumber daya Pod_ untuk jenis sumber daya tertentu adalah jumlah dari +request/limit sumber daya pada jenis tersebut untuk semua Container di dalam Pod tersebut. + +## Arti dari CPU + +Limit dan request untuk sumber daya CPU diukur dalam satuan _cpu_. +Satu cpu, dalam Kubernetes, adalah sama dengan: + +- 1 vCPU AWS +- 1 Core GCP +- 1 vCore Azure +- 1 vCPU IBM +- 1 *Hyperthread* pada sebuah prosesor Intel _bare-metal_ dengan Hyperthreading + +Request dalam bentuk pecahan diizinkan. Sebuah Container dengan +`spec.containers[].resources.requests.cpu` bernilai `0.5` dijamin mendapat +setengah CPU dibandingkan dengan yang meminta 1 CPU. Ekspresi nilai `0.1` ekuivalen +dengan ekspresi nilai `100m`, yang dapat dibaca sebagai "seratus milicpu". Beberapa +orang juga membacanya dengan "seratus milicore", dan keduanya ini dimengerti sebagai +hal yang sama. Sebuah request dengan angka di belakang koma, seperti `0.1` dikonversi +menjadi `100m` oleh API, dan presisi yang lebih kecil lagi dari `1m` tidak dibolehkan. +Untuk alasan ini, bentuk `100m` mungkin lebih disukai. + +CPU juga selalu diminta dalam jumlah yang mutlak, tidak sebagai jumlah yang relatif; +0.1 adalah jumlah CPU yang sama pada sebuah mesin _single-core_, _dual-core_, atau +_48-core_. + +## Arti dari Memori + +Limit dan request untuk `memory` diukur dalam satuan _bytes_. Kamu dapat mengekspresikan +memori sebagai _plain integer_ atau sebagai sebuah _fixed-point integer_ menggunakan +satu dari sufiks-sufiks berikut: E, P, T, G, M, K. Kamu juga dapat menggunakan bentuk +pangkat dua ekuivalennya: Ei, Pi, Ti, Gi, Mi, Ki. +Sebagai contoh, nilai-nilai berikut kurang lebih sama: + +```shell +128974848, 129e6, 129M, 123Mi +``` + +Berikut sebuah contoh. +Pod berikut memiliki dua Container. Setiap Container memiliki request 0.25 cpu dan +64MiB (226 bytes) memori. Setiap Container memiliki limit 0.5 cpu dan +128MiB memori. Kamu dapat berkata bahwa Pod tersebut memiliki request 0.5 cpu dan +128MiB memori, dan memiliki limit 1 cpu dan 265MiB memori. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +## Bagaimana Pod-Pod dengan request sumber daya dijadwalkan + +Saat kamu membuat sebuah Pod, Kubernetes scheduler akan memilih sebuah Node +untuk Pod tersebut untuk dijalankan. Setiap Node memiliki kapasitas maksimum +untuk setiap jenis sumber daya: jumlah CPU dan memori yang dapat disediakan +oleh Node tersebut untuk Pod-Pod. Scheduler memastikan bahwa, untuk setiap +jenis sumber daya, jumlah semua request sumber daya dari Container-Container +yang dijadwalkan lebih kecil dari kapasitas Node tersebut. Perlu dicatat +bahwa walaupun penggunaan sumber daya memori atau CPU aktual/sesungguhnya pada +Node-Node sangat rendah, scheduler tetap akan menolak untuk menaruh sebuah +Pod pada sebuah Node jika pemeriksaan kapasitasnya gagal. Hal ini adalah untuk +menjaga dari kekurangan sumber daya pada sebuah Node saat penggunaan sumber daya +meningkat suatu waktu, misalnya pada saat titik puncak _traffic_ harian. + +## Bagaimana Pod-Pod dengan limit sumber daya dijalankan + +Saat Kubelet menjalankan sebuah Container dari sebuah Pod, Kubelet tersebut +mengoper limit CPU dan memori ke _runtime_ kontainer. + +Ketika menggunakan Docker: + +- `spec.containers[].resources.requests.cpu` diubah menjadi nilai _core_-nya, + yang mungkin berbentuk angka pecahan, dan dikalikan dengan 1024. Nilai yang + lebih besar antara angka ini atau 2 digunakan sebagai nilai dari _flag_ + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) + pada perintah `docker run`. + +- `spec.containers[].resources.limits.cpu` diubah menjadi nilai _millicore_-nya dan + dikalikan dengan 100. Nilai hasilnya adalah jumlah waktu CPU yang dapat digunakan oleh + sebuah kontainer setiap 100 milidetik. Sebuah kontainer tidak dapat menggunakan lebih + dari jatah waktu CPU-nya selama selang waktu ini. + + {{< note >}} + Periode kuota bawaan adalah 100ms. Resolusi minimum dari kuota CPU adalah 1 milidetik. + {{}} + +- `spec.containers[].resources.limits.memory` diubah menjadi sebuah bilangan bulat, dan + digunakan sebagai nilai dari _flag_ [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + dari perintah `docker run`. + +Jika sebuah Container melebihi batas memorinya, Container tersebut mungkin akan diterminasi. +Jika Container tersebut dapat diulang kembali, Kubelet akan mengulangnya kembali, sama +seperti jenis kegagalan lainnya. + +Jika sebuah Container melebihi request memorinya, kemungkinan Pod-nya akan dipindahkan +kapanpun Node tersebut kehabisan memori. + +Sebuah Container mungkin atau mungkin tidak diizinkan untuk melebihi limit CPU-nya +untuk periode waktu yang lama. Tetapi, Container tersebut tidak akan diterminasi karena +penggunaan CPU yang berlebihan. + +Untuk menentukan apabila sebuah Container tidak dapat dijadwalkan atau sedang diterminasi +karena limit sumber dayanya, lihat bagian [Penyelesaian Masalah](#penyelesaian-masalah). + +## Memantau penggunaan sumber daya komputasi + +Penggunaan sumber daya dari sebuah Pod dilaporkan sebagai bagian dari kondisi Pod. + +Jika [_monitoring_ opsional](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md) diaktifkan pada klaster kamu, maka penggunaan sumber daya Pod dapat diambil +dari sistem _monitoring_ kamu. + +## Penyelesaian Masalah + +### Pod-Pod saya berkondisi Pending (tertunda) dengan _event message_ failedScheduling + +Jika scheduler tidak dapat menemukan Node manapun yang muat untuk sebuah Pod, +Pod tersebut tidak akan dijadwalkan hingga ditemukannya sebuah tempat yang +muat. Sebuah _event_ akan muncul setiap kali scheduler gagal menemukan tempat +untuk Pod tersebut, seperti berikut: + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + +Pada contoh di atas, Pod bernama "frontend" gagal dijadwalkan karena kekurangan +sumber daya CPU pada Node tersebut. Pesan kesalahan yang serupa dapat juga menunjukkan +kegagalan karena kekurangan memori (PodExceedsFreeMemroy). Secara umum, jika sebuah +Pod berkondisi Pending (tertunda) dengan sebuah pesan seperti ini, ada beberapa hal yang +dapat dicoba: + +- Tambah lebih banyak Node pada klaster. +- Terminasi Pod-Pod yang tidak dibutuhkan untuk memberikan ruangan untuk Pod-Pod yang + tertunda. +- Periksa jika nilai request Pod tersebut tidak lebih besar dari Node-node yang ada. + Contohnya, jika semua Node memiliki kapasitas `cpu: 1`, maka Pod dengan request + `cpu: 1.1` tidak akan pernah dijadwalkan. + +Kamu dapat memeriksa kapasitas Node-Node dan jumlah-jumlah yang telah dialokasikan +dengan perintah `kubectl describe nodes`. Contohnya: + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... lines removed for clarity ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... beberapa baris dihapus untuk kejelasan ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limit mungkin melebihi 100 persen, misalnya, karena _overcommit_.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + +Pada keluaran di atas, kamu dapat melihat bahwa jika sebuah Pod meminta lebih dari +1120m CPU atau 6.23Gi memori, Pod tersebut tidak akan muat pada Node tersebut. + +Dengan melihat pada bagian `Pods`, kamu dapat melihat Pod-Pod mana saja yang memakan +sumber daya pada Node tersebut. +Jumlah sumber daya yang tersedia untuk Pod-Pod kurang dari kapasitas Node, karena +_daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatable` pada +[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) +memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat +[Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). + +Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk +membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace, +kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya. + +### Container saya diterminasi + +Container kamu mungkin diterminasi karena Container tersebut melebihi batasnya. Untuk +memeriksa jika sebuah Container diterminasi karena ia melebihi batas sumber dayanya, +gunakan perintah `kubectl describe pod` pada Pod yang bersangkutan: + +```shell +kubectl describe pod simmemleak-hra99 +``` +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + +Pada contoh di atas, `Restart Count: 5` menunjukkan bahwa Container `simmemleak` +pada Pod tersebut diterminasi dan diulang kembali sebanyak lima kali. + +Kamu dapat menggunakan perintah `kubectl get pod` dengan opsi `-o go-template=...` untuk +mengambil kondisi dari Container-Container yang sebelumnya diterminasi: + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + +Kamu dapat lihat bahwa Container tersebut diterminasi karena `reason:OOM Killed`, di mana +`OOM` merupakan singkatan dari _Out Of Memory_, atau kehabisan memori. + + +## Penyimpanan lokal sementara +{{< feature-state state="beta" >}} + +Kubernetes versi 1.8 memperkenalkan sebuah sumber daya baru, _ephemeral-storage_ untuk mengatur penyimpanan lokal yang bersifat sementara. Pada setiap Node Kubernetes, direktori _root_ dari Kubelet (secara bawaan /var/lib/kubelet) dan direktori log (/var/log) ditaruh pada partisi _root_ dari Node tersebut. Partisi ini juga digunakan bersama oleh Pod-Pod melalui volume emptyDir, log kontainer, lapisan _image_, dan lapisan kontainer yang dapat ditulis. + +Partisi ini bersifat "sementara" dan aplikasi-aplikasi tidak dapat mengharapkan SLA kinerja (misalnya _Disk IOPS_) dari partisi ini. Pengelolaan penyimpanan lokal sementara hanya berlaku untuk partisi _root_; partisi opsional untuk lapisan _image_ dan lapisan yang dapat ditulis berada di luar ruang lingkup. + +{{< note >}} +Jika sebuah partisi _runtime_ opsional digunakan, partisi _root_ tidak akan menyimpan lapisan _image_ ataupun lapisan yang dapat ditulis manapun. +{{< /note >}} + +### Menyetel request dan limit dari penyimpanan lokal sementara + +Setiap Container dari sebuah Pod dapat menentukan satu atau lebih dari hal-hal berikut: + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +Limit dan request untuk `ephemeral-storage` diukur dalam satuan _bytes_. Kamu dapat menyatakan +penyimpanan dalam bilangan bulat biasa, atau sebagai _fixed-point integer_ menggunakan satu dari +sufiks-sufiks ini: E, P, T, G, M, K. Kamu jika dapat menggunakan bentuk pangkat dua ekuivalennya: +Ei, Pi, Ti, Gi, Mi, Ki. Contohnya, nilai-nilai berikut kurang lebih sama: + +```shell +128974848, 129e6, 129M, 123Mi +``` + +Contohnya, Pod berikut memiliki dua Container. Setiap Container memiliki request 2GiB untuk penyimpanan lokal sementara. Setiap Container memiliki limit 4GiB untuk penyimpanan lokal sementara. Maka, Pod tersebut memiliki jumlah request 4GiB penyimpanan lokal sementara, dan limit 8GiB. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + +### Bagaimana Pod-Pod dengan request ephemeral-storage dijadwalkan + +Saat kamu membuat sebuah Pod, Kubernetes scheduler memilih sebuah Node di mana Pod +tersebut akan dijalankan. Setiap Node memiliki jumlah maksimum penyimpanan lokal sementara yang dapat disediakan. +Untuk lebih lanjut, lihat ["Hal-hal yang dapat dialokasikan Node"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). + +Scheduler memastikan bahwa jumlah dari request-request sumber daya dari Container-Container yang dijadwalkan lebih kecil dari kapasitas Node. + +### Bagaimana Pod-Pod dengan limit ephemeral-storage dijalankan + +Untuk isolasi pada tingkat kontainer, jika lapisan yang dapat ditulis dari sebuah Container dan penggunaan log melebihi limit penyimpanannya, maka Pod tersebut akan dipindahkan. Untuk isolasi pada tingkat Pod, jika jumlah dari penyimpanan lokal sementara dari semua Container dan juga volume emptyDir milik Pod melebihi limit, maka Pod teresebut akan dipindahkan. + +### Memantau penggunaan ephemeral-storage + +Saat penyimpanan lokal sementara digunakan, ia dipantau terus-menerus +oleh Kubelet. Pemantauan dilakukan dengan cara memindai setiap volume +emptyDir, direktori log, dan lapisan yang dapat ditulis secara periodik. +Dimulai dari Kubernetes 1.15, volume emptyDir (tetapi tidak direktori log +atau lapisan yang dapat ditulis) dapat, sebagai pilihan dari operator +klaster, dikelola dengan menggunakan [_project quotas_](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html). +_Project quotas_ aslinya diimplementasikan dalam XFS, dan baru-baru ini +telah diubah ke ext4fs. _Project quotas_ dapat digunakan baik untuk +_monitoring_ dan pemaksaan; sejak Kubernetes 1.16, mereka tersedia sebagai +fitur _alpha_ untuk _monitoring_ saja. + +_Quota_ lebih cepat dan akurat dibandingkan pemindaian direktori. Saat +sebuah direktori ditentukan untuk sebuah proyek, semua berkas yang dibuat +pada direktori tersebut dibuat untuk proyek tersebut, dan kernel hanya +perlu melacak berapa banyak blok yang digunakan oleh berkas-berkas pada +proyek tersebut. Jika sebuah berkas dibuat dan dihapus, tetapi tetap dengan +sebuah _file descriptor_ yang terbuka, maka berkas tersebut tetap akan +memakan ruangan penyimpanan. Ruangan ini akan dilacak oleh _quota_ tersebut, +tetapi tidak akan terlihat oleh sebuah pemindaian direktori. + +Kubernetes menggunakan ID proyek yang dimulai dari 1048576. ID-ID yang +digunakan akan didaftarkan di dalam `/etc/projects` dan `/etc/projid`. +Jika ID-ID proyek pada kisaran ini digunakan untuk tujuan lain pada sistem, +ID-ID proyek tersebut harus terdaftar di dalam `/etc/projects` dan `/etc/projid` +untuk mencegah Kubernetes menggunakan ID-ID tersebut. + +Untuk mengaktifkan penggunaan _project quotas_, operator klaster +harus melakukan hal-hal berikut: + +* Aktifkan _feature gate_ `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + pada konfigurasi Kubelet. Nilainya secara bawaan `false` pada + Kubernetes 1.16, jadi harus secara eksplisit disetel menjadi `true`. + +* Pastikan bahwa partisi _root_ (atau partisi opsional _runtime_) + telah dibangun (_build_) dengan mengaktifkan _project quotas_. Semua sistem berkas (_filesystem_) + XFS mendukung _project quotas_, tetapi sistem berkas ext4 harus dibangun + secara khusus untuk mendukungnya + +* Pastikan bahwa partisi _root_ (atau partisi opsional _runtime_) ditambatkan (_mount_) + dengan _project quotas_ yang telah diaktifkan. + +#### Membangun dan menambatkan sistem berkas dengan _project quotas_ yang telah diaktifkan + +Sistem berkas XFS tidak membutuhkan tindakan khusus saat dibangun; +mereka secara otomatis telah dibangun dengan _project quotas_ yang +telah diaktifkan. + +Sistem berkas _ext4fs_ harus dibangun dengan mengaktifkan _quotas_, +kemudian mereka harus diaktifkan pada sistem berkas tersebut. + +``` +% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device +% sudo tune2fs -O project -Q prjquota /dev/block_device +``` + +Untuk menambatkan sistem berkasnya, baik ext4fs dan XFS membutuhkan opsi +`prjquota` disetel di dalam `/etc/fstab`: + +``` +/dev/block_device /var/kubernetes_data defaults,prjquota 0 0 +``` + + +## Sumber daya yang diperluas + +Sumber daya yang diperluas (_Extended Resource_) adalah nama sumber daya di luar domain `kubernetes.io`. +Mereka memungkinkan operator klaster untuk menyatakan dan pengguna untuk menggunakan +sumber daya di luar sumber daya bawaan Kubernetes. + +Ada dua langkah untuk menggunakan sumber daya yang diperluas. Pertama, operator +klaster harus menyatakan sebuah Extended Resource. Kedua, pengguna harus meminta +sumber daya yang diperluas tersebut di dalam Pod. + +### Mengelola sumber daya yang diperluas + +#### Sumber daya yang diperluas pada tingkat Node + +Sumber daya yang diperluas pada tingkat Node terikat pada Node. + +##### Sumber daya Device Plugin yang dikelola + +Lihat [Device +Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk +cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node. + +##### Sumber daya lainnya + +Untuk menyatakan sebuah sumber daya yang diperluas tingkat Node, operator klaster +dapat mengirimkan permintaan HTTP `PATCH` ke API server untuk menentukan kuantitas +sumber daya yang tersedia pada kolom `status.capacity` untuk Node pada klaster. +Setelah itu, `status.capacity` pada Node akan memiliki sumber daya baru tersebut. +Kolom `status.allocatable` diperbarui secara otomatis dengan sumber daya baru +tersebut secara _asynchrounous_ oleh Kubelet. Perlu dicatat bahwa karena scheduler +menggunakan nilai `status.allocatable` milik Node saat mengevaluasi muat atau tidaknya +Pod, mungkin ada waktu jeda pendek antara melakukan `PATCH` terhadap kapasitas Node +dengan sumber daya baru dengan Pod pertama yang meminta sumber daya tersebut untuk +dapat dijadwalkan pada Node tersebut. + +**Contoh:** + +Berikut sebuah contoh yang menunjukkan bagaimana cara menggunakan `curl` untuk +mengirim permintaan HTTP yang menyatakan lima sumber daya "example.com/foo" pada +Node `k8s-node-1` yang memiliki master `k8s-master`. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + +{{< note >}} +Pada permintaan HTTP di atas, `~1` adalah _encoding_ untuk karakter `/` pada jalur (_path_) _patch_. +Nilai jalur operasi tersebut di dalam JSON-Patch diinterpretasikan sebagai sebuah JSON-Pointer. +Untuk lebih lanjut, lihat [IETF RFC 6901, bagian 3](https://tools.ietf.org/html/rfc6901#section-3). +{{< /note >}} + +#### Sumber daya yang diperluas pada tingkat klaster + +Sumber daya yang diperluas pada tingkat klaster tidak terikat pada Node. Mereka +biasanya dikelola oleh _scheduler extender_, yang menangani penggunaan sumber daya +dan kuota sumber daya. + +Kamu dapat menentukan sumber daya yang diperluas yang ditangani oleh _scheduler extender_ +pada [konfigurasi kebijakan scheduler](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31). + +**Contoh:** + +Konfigurasi untuk sebuah kebijakan scheduler berikut menunjukkan bahwa +sumber daya yang diperluas pada tingkat klaster "example.com/foo" ditangani +oleh _scheduler extender_. + +- Scheduler mengirim sebuah Pod ke _scheduler extender_ hanya jika Pod tersebut + meminta "example.com/foo". +- Kolom `ignoredByScheduler` menentukan bahwa scheduler tidak memeriksa sumber daya + "example.com/foo" pada predikat `PodFitsResources` miliknya. + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +### Menggunakan sumber daya yang diperluas + +Pengguna dapat menggunakan sumber daya yang diperluas di dalam spesifikasi Pod +seperti CPU dan memori. Scheduler menangani akuntansi sumber daya tersebut agar +tidak ada alokasi untuk yang melebihi jumlah yang tersedia. + +API server membatasi jumlah sumber daya yang diperluas dalam bentuk +bilangan bulat. Contoh jumlah yang _valid_ adalah `3`, `3000m`, dan +`3Ki`. Contoh jumlah yang _tidak valid_ adalah `0.5` dan `1500m`. + +{{< note >}} +Sumber daya yang diperluas menggantikan Opaque Integer Resource. +Pengguna dapat menggunakan prefiks nama domain selain `kubernetes.io` yang sudah dipakai. +{{< /note >}} + +Untuk menggunakan sebuah sumber daya yang diperluas di sebuah Pod, masukkan nama +sumber daya tersebut sebagai nilai _key_ dari map `spec.containers[].resources.limit` +pada spesifikasi Container. + +{{< note >}} +Sumber daya yang diperluas tidak dapat di-_overcommit_, sehingga +request dan limit nilainya harus sama jika keduanya ada di spesifikasi +sebuah Container. +{{< /note >}} + +Sebuah Pod hanya dijadwalkan jika semua request sumber dayanya terpenuhi, termasuk +CPU, memori, dan sumber daya yang diperluas manapun. Pod tersebut akan tetap +berada pada kondisi `PENDING` selama request sumber daya tersebut tidak terpenuhi. + +**Contoh:** + +Pod di bawah meminta 2 CPU dan 1 "example.com/foo" (sebuah sumber daya yang diperluas). + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + + + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* Dapatkan pengalaman langsung [menentukan sumber daya memori untuk Container dan Pod](/docs/tasks/configure-pod-container/assign-memory-resource/). + +* Dapatkan pengalaman langsung [menentukan sumber daya CPU untuk Container dan Pod](/docs/tasks/configure-pod-container/assign-cpu-resource/). + +* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) + +* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) + +{{% /capture %}} diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/_index.md new file mode 100644 index 0000000000..3df1ff1bdc --- /dev/null +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/_index.md @@ -0,0 +1,4 @@ +--- +title: Ekstensi Komputasi, Penyimpanan, dan Jaringan +weight: 30 +--- diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md new file mode 100644 index 0000000000..beb972e9bf --- /dev/null +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -0,0 +1,234 @@ +--- +reviewers: +title: Plugin Perangkat +description: Gunakan kerangka kerja _plugin_ perangkat Kubernetes untuk mengimplementasikan plugin untuk GPU, NIC, FPGA, InfiniBand, dan sumber daya sejenis yang membutuhkan setelan spesifik vendor. +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +Kubernetes menyediakan [kerangka kerja _plugin_ perangkat](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md) +sehingga kamu dapat memakainya untuk memperlihatkan sumber daya perangkat keras sistem ke dalam {{< glossary_tooltip term_id="kubelet" >}}. + +Daripada menkustomisasi kode Kubernetes itu sendiri, vendor dapat mengimplementasikan +_plugin_ perangkat yang di-_deploy_ secara manual atau sebagai {{< glossary_tooltip term_id="daemonset" >}}. +Perangkat yang dituju termasuk GPU, NIC berkinerja tinggi, FPGA, adaptor InfiniBand, +dan sumber daya komputasi sejenis lainnya yang perlu inisialisasi dan setelan spesifik vendor. + +{{% /capture %}} + +{{% capture body %}} + +## Pendaftaran _plugin_ perangkat + +Kubelet mengekspor servis gRPC `Registration`: + +```gRPC +service Registration { + rpc Register(RegisterRequest) returns (Empty) {} +} +``` + +Plugin perangkat bisa mendaftarkan dirinya sendiri dengan kubelet melalui servis gRPC. +Dalam pendaftaran, _plugin_ perangkat perlu mengirim: + + * Nama Unix socket-nya. + * Versi API Plugin Perangkat yang dipakai. + * `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti + [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + sebagai `vendor-domain/tipe-sumber-daya`. + (Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.) + +Setelah registrasi sukses, _plugin_ perangkat mengirim daftar perangkat yang diatur +ke kubelet, lalu kubelet kemudian bertanggung jawab untuk mengumumkan sumber daya tersebut +ke peladen API sebagai bagian pembaruan status node kubelet. +Contohnya, setelah _plugin_ perangkat mendaftarkan `hardware-vendor.example/foo` dengan kubelet +dan melaporkan kedua perangkat dalam node dalam kondisi sehat, status node diperbarui +untuk menunjukkan bahwa node punya 2 perangkat “Foo” terpasang dan tersedia. + +Kemudian, pengguna dapat meminta perangkat dalam spesifikasi +[Kontainer](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +seperti meminta tipe sumber daya lain, dengan batasan berikut: + +* Sumber daya ekstensi hanya didukung sebagai sumber daya integer dan tidak bisa _overcommitted_. +* Perangkat tidak bisa dibagikan antar Kontainer. + +Semisal klaster Kubernetes menjalankan _plugin_ perangkat yang menunjukkan sumber daya `hardware-vendor.example/foo` +pada node tertentu. Berikut contoh Pod yang meminta sumber daya itu untuk menjalankan demo beban kerja: + +```yaml +--- +apiVersion: v1 +kind: Pod +metadata: + name: demo-pod +spec: + containers: + - name: demo-container-1 + image: k8s.gcr.io/pause:2.0 + resources: + limits: + hardware-vendor.example/foo: 2 +# +# Pod ini perlu 2 perangkat perangkat-vendor.example/foo +# dan hanya dapat menjadwalkan ke Node yang bisa memenuhi +# kebutuhannya. +# +# Jika Node punya lebih dari 2 perangkat tersedia, +# maka kelebihan akan dapat digunakan Pod lainnya. +``` + +## Implementasi _plugin_ perangkat + +Alur kerja umum dari _plugin_ perangkat adalah sebagai berikut: + +* Inisiasi. Selama fase ini, _plugin_ perangkat melakukan inisiasi spesifik vendor + dan pengaturan untuk memastikan perangkat pada status siap. + +* Plugin memulai servis gRPC, dengan Unix socket pada lokasi + `/var/lib/kubelet/device-plugins/`, yang mengimplementasi antarmuka berikut: + + ```gRPC + service DevicePlugin { + // ListAndWatch mengembalikan aliran dari List of Devices + // Kapanpun Device menyatakan perubahan atau kehilangan Device, ListAndWatch + // mengembalikan daftar baru + rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {} + + // Allocate dipanggil saat pembuatan kontainer sehingga Device + // Plugin dapat menjalankan operasi spesifik perangkat dan menyuruh Kubelet + // dari operasi untuk membuat Device tersedia di kontainer + rpc Allocate(AllocateRequest) returns (AllocateResponse) {} + } + ``` + +* Plugin mendaftarkan dirinya sendiri dengan kubelet melalui Unix socket pada lokasi host + `/var/lib/kubelet/device-plugins/kubelet.sock`. + +* Seteleh sukses mendaftarkan dirinya sendiri, _plugin_ perangkat berjalan dalam mode peladen, dan selama itu +dia tetap mengawasi kesehatan perangkat dan melaporkan balik ke kubelet terhadap perubahan status perangkat. +Dia juga bertanggung jawab untuk melayani _request_ gRPC `Allocate`. Selama `Allocate`, _plugin_ perangkat dapat +membuat persiapan spesifik-perangkat; contohnya, pembersihan GPU atau inisiasi QRNG. +Jika operasi berhasil, _plugin_ perangkat mengembalikan `AllocateResponse` yang memuat konfigurasi +runtime kontainer untuk mengakses perangkat teralokasi. Kubelet memberikan informasi ini ke runtime kontainer. + +### Menangani kubelet yang _restart_ + +Plugin perangkat diharapkan dapat mendeteksi kubelet yang _restart_ dan mendaftarkan dirinya sendiri kembali dengan +_instance_ kubelet baru. Pada implementasi sekarang, sebuah _instance_ kubelet baru akan menghapus semua socket Unix yang ada +di dalam `/var/lib/kubelet/device-plugins` ketika dijalankan. Plugin perangkat dapat mengawasi penghapusan +socket Unix miliknya dan mendaftarkan dirinya sendiri kembali ketika hal tersebut terjadi. + +## Deployment _plugin_ perangkat + +Kamu dapat melakukan _deploy_ sebuah _plugin_ perangkat sebagai DaemonSet, sebagai sebuah paket untuk sistem operasi node-mu, +atau secara manual. + +Direktori _canonical_ `/var/lib/kubelet/device-plugins` membutuhkan akses berprivilese, +sehingga _plugin_ perangkat harus berjalan dalam konteks keamanan dengan privilese. +Jika kamu melakukan _deploy_ _plugin_ perangkat sebagai DaemonSet, `/var/lib/kubelet/device-plugins` +harus dimuat sebagai {{< glossary_tooltip term_id="volume" >}} pada +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +plugin. + +Jika kamu memilih pendekatan DaemonSet, kamu dapat bergantung pada Kubernetes untuk meletakkan Pod +_plugin_ perangkat ke Node, memulai-ulang Pod daemon setelah kegagalan, dan membantu otomasi pembaruan. + +## Kecocokan API + +Dukungan pada _plugin_ perangkat Kubernetes sedang dalam beta. API dapat berubah hingga stabil, +dalam cara yang tidak kompatibel. Sebagai proyek, Kubernetes merekomendasikan para developer _plugin_ perangkat: + +* Mengamati perubahan pada rilis mendatang. +* Mendukung versi API _plugin_ perangkat berbeda untuk kompatibilitas-maju/mundur. + +Jika kamu menyalakan fitur DevicePlugins dan menjalankan _plugin_ perangkat pada node yang perlu diperbarui +ke rilis Kubernetes dengan versi API plugin yang lebih baru, perbarui _plugin_ perangkatmu +agar mendukung kedua versi sebelum membarui para node ini. Memilih pendekatan demikian akan +menjamin fungsi berkelanjutan dari alokasi perangkat selama pembaruan. + +## Mengawasi Sumber Daya Plugin Perangkat + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +Dalam rangka mengawasi sumber daya yang disediakan _plugin_ perangkat, agen monitoring perlu bisa +menemukan kumpulan perangkat yang terpakai dalam node dan mengambil metadata untuk mendeskripsikan +pada kontainer mana metrik harus diasosiasikan. Metrik [prometheus](https://prometheus.io/) +diekspos oleh agen pengawas perangkat harus mengikuti +[Petunjuk Instrumentasi Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md), +mengidentifikasi kontainer dengan label prometheus `pod`, `namespace`, dan `container`. + +Kubelet menyediakan servis gRPC untuk menyalakan pencarian perangkat yang terpakai, dan untuk menyediakan metadata +untuk perangkat berikut: + +```gRPC +// PodResourcesLister adalah layanan yang disediakan kubelet untuk menyediakan informasi tentang +// sumber daya node yang dikonsumsi Pod dan kontainer pada node +service PodResourcesLister { + rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {} +} +``` + +Servis gRPC dilayani lewat socket unix pada `/var/lib/kubelet/pod-resources/kubelet.sock`. +Agen pengawas untuk sumber daya _plugin_ perangkat dapat di-_deploy_ sebagai daemon, atau sebagai DaemonSet. +Direktori _canonical_ `/var/lib/kubelet/pod-resources` perlu akses berprivilese, +sehingga agen pengawas harus berjalan dalam konteks keamanan dengan privilese. Jika agen pengawas perangkat berjalan +sebagai DaemonSet, `/var/lib/kubelet/pod-resources` harus dimuat sebagai +{{< glossary_tooltip term_id="volume" >}} pada plugin +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). + +Dukungan untuk "servis PodResources" butuh [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gates/) +`KubeletPodResources` untuk dinyalakan. Mulai dari Kubernetes 1.15 nilai bawaannya telah dinyalakan. + +## Integrasi Plugin Perangkat dengan Topology Manager + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +Topology Manager adalah komponen Kubelet yang membolehkan sumber daya untuk dikoordinasi secara selaras dengan Topology. Untuk melakukannya, API Plugin Perangkat telah dikembangkan untuk memasukkan struct `TopologyInfo`. + + +```gRPC +message TopologyInfo { + repeated NUMANode nodes = 1; +} + +message NUMANode { + int64 ID = 1; +} +``` +Plugin Perangkat yang ingin memanfaatkan Topology Manager dapat mengembalikan beberapa _struct_ TopologyInfo sebagai bagian dari pendaftaran perangkat, bersama dengan ID perangkat dan status kesehatan perangkat. Manajer perangkat akan memakai informasi ini untuk konsultasi dengan Topology Manager dan membuat keputusan alokasi sumber daya. + +`TopologyInfo` mendukung kolom `nodes` yang bisa `nil` (sebagai bawaan) atau daftar node NUMA. Ini membuat Plugin Perangkat mengumumkan apa saja yang bisa meliputi node NUMA. + +Contoh _struct_ `TopologyInfo` untuk perangkat yang dipopulate oleh Plugin Perangkat: + +``` +pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}} +``` + +## Contoh _plugin_ perangkat {#contoh} + +Berikut beberapa contoh implementasi _plugin_ perangkat: + +* [Plugin perangkat AMD GPU](https://github.com/RadeonOpenCompute/k8s-device-plugin) +* [Plugin perangkat Intel](https://github.com/intel/intel-device-plugins-for-kubernetes) untuk perangkat GPU, FPGA, dan QuickAssist Intel +* [Plugin perangkat KubeVirt](https://github.com/kubevirt/kubernetes-device-plugins) untuk virtualisasi hardware-assisted +* [Plugin perangkat NVIDIA GPU](https://github.com/NVIDIA/k8s-device-plugin) + * Perlu [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) versi 2.0 yang memungkinkan untuk menjalakan kontainer Docker yang memuat GPU. +* [Plugin perangkat NVIDIA GPU untuk Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) +* [Plugin perangkat RDMA](https://github.com/hustcat/k8s-rdma-device-plugin) +* [Plugin perangkat Solarflare](https://github.com/vikaschoudhary16/sfc-device-plugin) +* [Plugin perangkat SR-IOV Network](https://github.com/intel/sriov-network-device-plugin) +* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) untuk perangkat Xilinx FPGA + +{{% /capture %}} +{{% capture whatsnext %}} + +* Pelajari bagaimana [menjadwalkan sumber daya GPU](/docs/tasks/manage-gpus/scheduling-gpus/) dengan _plugin_ perangkat +* Pelajari bagaimana [mengumumkan sumber daya ekstensi](/docs/tasks/administer-cluster/extended-resource-node/) pada node +* Baca tentang penggunaan [akselerasi perangkat keras untuk ingress TLS](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) dengan Kubernetes +* Pelajari tentang [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) + +{{% /capture %}} diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md new file mode 100644 index 0000000000..7bf34d22d4 --- /dev/null +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -0,0 +1,158 @@ +--- +title: Plugin Jaringan +content_template: templates/concept +weight: 10 +--- + + +{{% capture overview %}} + +{{< feature-state state="alpha" >}} +{{< warning >}}Fitur-fitur Alpha berubah dengan cepat. {{< /warning >}} + +_Plugin_ jaringan di Kubernetes hadir dalam beberapa varian: + +* _Plugin_ CNI : mengikuti spesifikasi appc / CNI, yang dirancang untuk interoperabilitas. +* _Plugin_ Kubenet : mengimplementasi `cbr0` sederhana menggunakan _plugin_ `bridge` dan `host-local` CNI + +{{% /capture %}} + +{{% capture body %}} + +## Instalasi + +Kubelet memiliki _plugin_ jaringan bawaan tunggal, dan jaringan bawaan umum untuk seluruh kluster. _Plugin_ ini memeriksa _plugin-plugin_ ketika dijalankan, mengingat apa yang ditemukannya, dan mengeksekusi _plugin_ yang dipilih pada waktu yang tepat dalam siklus pod (ini hanya berlaku untuk Docker, karena rkt mengelola _plugin_ CNI sendiri). Ada dua parameter perintah Kubelet yang perlu diingat saat menggunakan _plugin_: + +* `cni-bin-dir`: Kubelet memeriksa direktori ini untuk _plugin-plugin_ saat _startup_ +* `network-plugin`: _Plugin_ jaringan untuk digunakan dari `cni-bin-dir`. Ini harus cocok dengan nama yang dilaporkan oleh _plugin_ yang diperiksa dari direktori _plugin_. Untuk _plugin_ CNI, ini (nilainya) hanyalah "cni". + +## Persyaratan _Plugin_ Jaringan + +Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi ` 1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi. + +Secara bawaan jika tidak ada _plugin_ jaringan Kubelet yang ditentukan, _plugin_ `noop` digunakan, yang menetapkan `net/bridge/bridge-nf-call-iptables=1` untuk memastikan konfigurasi sederhana (seperti Docker dengan sebuah _bridge_) bekerja dengan benar dengan proksi _iptables_. + +### CNI + +_Plugin_ CNI dipilih dengan memberikan opsi _command-line_ `--network-plugin=cni` pada Kubelet. Kubelet membaca berkas dari `--cni-conf-dir` (bawaan `/etc/cni/net.d`) dan menggunakan konfigurasi CNI dari berkas tersebut untuk mengatur setiap jaringan Pod. Berkas konfigurasi CNI harus sesuai dengan [spesifikasi CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), dan setiap _plugin_ CNI yang diperlukan oleh konfigurasi harus ada di `--cni-bin-dir` (nilai bawaannya adalah `/opt/cni/bin`). + +Jika ada beberapa berkas konfigurasi CNI dalam direktori, Kubelet menggunakan berkas yang pertama dalam urutan abjad. + +Selain plugin CNI yang ditentukan oleh berkas konfigurasi, Kubernetes memerlukan _plugin_ CNI standar [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) _plugin_ , minimal pada versi 0.2.0. + +#### Dukungan hostPort + +_Plugin_ jaringan CNI mendukung `hostPort`. Kamu dapat menggunakan _plugin_ [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) resmi yang ditawarkan oleh tim _plugin_ CNI atau menggunakan _plugin_ kamu sendiri dengan fungsionalitas _portMapping_. + +Jika kamu ingin mengaktifkan dukungan `hostPort`, kamu harus menentukan `portMappings capability` di `cni-conf-dir` kamu. +Contoh: + +```json +{ + "name": "k8s-pod-network", + "cniVersion": "0.3.0", + "plugins": [ + { + "type": "calico", + "log_level": "info", + "datastore_type": "kubernetes", + "nodename": "127.0.0.1", + "ipam": { + "type": "host-local", + "subnet": "usePodCidr" + }, + "policy": { + "type": "k8s" + }, + "kubernetes": { + "kubeconfig": "/etc/cni/net.d/calico-kubeconfig" + } + }, + { + "type": "portmap", + "capabilities": {"portMappings": true} + } + ] +} +``` + +#### Dukungan pembentukan lalu-lintas + +_Plugin_ jaringan CNI juga mendukung pembentukan lalu-lintas yang masuk dan keluar dari Pod. Kamu dapat menggunakan _plugin_ resmi [_bandwidth_](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) yang ditawarkan oleh tim _plugin_ CNI atau menggunakan _plugin_ kamu sendiri dengan fungsionalitas kontrol _bandwidth_. + +Jika kamu ingin mengaktifkan pembentukan lalu-lintas, kamu harus menambahkan _plugin_ `bandwidth` ke berkas konfigurasi CNI kamu (nilai bawaannya adalah `/etc/cni/ net.d`). + +```json +{ + "name": "k8s-pod-network", + "cniVersion": "0.3.0", + "plugins": [ + { + "type": "calico", + "log_level": "info", + "datastore_type": "kubernetes", + "nodename": "127.0.0.1", + "ipam": { + "type": "host-local", + "subnet": "usePodCidr" + }, + "policy": { + "type": "k8s" + }, + "kubernetes": { + "kubeconfig": "/etc/cni/net.d/calico-kubeconfig" + } + }, + { + "type": "bandwidth", + "capabilities": {"bandwidth": true} + } + ] +} +``` + +Sekarang kamu dapat menambahkan anotasi `kubernetes.io/ingress-bandwidth` dan `kubernetes.io/egress-bandwidth` ke Pod kamu. +Contoh: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + annotations: + kubernetes.io/ingress-bandwidth: 1M + kubernetes.io/egress-bandwidth: 1M +... +``` + +### Kubenet + +Kubenet adalah _plugin_ jaringan yang sangat mendasar dan sederhana, hanya untuk Linux. Ia, tidak dengan sendirinya, mengimplementasi fitur-fitur yang lebih canggih seperti jaringan _cross-node_ atau kebijakan jaringan. Ia biasanya digunakan bersamaan dengan penyedia layanan cloud yang menetapkan aturan _routing_ untuk komunikasi antar Node, atau dalam lingkungan Node tunggal. + +Kubenet membuat _bridge_ Linux bernama `cbr0` dan membuat pasangan _veth_ untuk setiap Pod dengan ujung _host_ dari setiap pasangan yang terhubung ke `cbr0`. Ujung Pod dari pasangan diberi alamat IP yang dialokasikan dari rentang yang ditetapkan untuk Node baik melalui konfigurasi atau oleh controller-manager. `cbr0` memiliki MTU yang cocok dengan MTU terkecil dari antarmuka normal yang diaktifkan pada _host_. + +_Plugin_ ini memerlukan beberapa hal: + +* _Plugin_ CNI `bridge`, `lo` dan `host-local` standar diperlukan, minimal pada versi 0.2.0. Kubenet pertama-tama akan mencari mereka di `/opt/cni/bin`. Tentukan `cni-bin-dir` untuk menyediakan lokasi pencarian tambahan. Hasil pencarian pertama akan digunakan. +* Kubelet harus dijalankan dengan argumen `--network-plugin=kubenet` untuk mengaktifkan _plugin_ +* Kubelet juga harus dijalankan dengan argumen `--non-masquerade-cidr=` untuk memastikan lalu-lintas ke IP-IP di luar rentang ini akan menggunakan _masquerade_ IP. +* Node harus diberi subnet IP melalui perintah kubelet `--pod-cidr` atau perintah controller-manager `--allocate-node-cidrs=true --cluster-cidr=`. + +### Menyesuaikan MTU (dengan kubenet) + +MTU harus selalu dikonfigurasi dengan benar untuk mendapatkan kinerja jaringan terbaik. _Plugin_ jaringan biasanya akan mencoba membuatkan MTU yang masuk akal, tetapi terkadang logika tidak akan menghasilkan MTU yang optimal. Misalnya, jika _bridge_ Docker atau antarmuka lain memiliki MTU kecil, kubenet saat ini akan memilih MTU tersebut. Atau jika kamu menggunakan enkapsulasi IPSEC, MTU harus dikurangi, dan perhitungan ini di luar cakupan untuk sebagian besar _plugin_ jaringan. + +Jika diperlukan, kamu dapat menentukan MTU secara eksplisit dengan opsi `network-plugin-mtu` kubelet. Sebagai contoh, pada AWS `eth0` MTU biasanya adalah 9001, jadi kamu dapat menentukan `--network-plugin-mtu=9001`. Jika kamu menggunakan IPSEC, kamu dapat menguranginya untuk memungkinkan/mendukung _overhead_ enkapsulasi pada IPSEC, contoh: `--network-plugin-mtu=8873`. + +Opsi ini disediakan untuk _plugin_ jaringan; Saat ini **hanya kubenet yang mendukung `network-plugin-mtu`**. + +## Ringkasan Penggunaan + +* `--network-plugin=cni` menetapkan bahwa kita menggunakan _plugin_ jaringan `cni` dengan _binary-binary plugin_ CNI aktual yang terletak di `--cni-bin-dir` (nilai bawaannya `/opt/cni/bin`) dan konfigurasi _plugin_ CNI yang terletak di `--cni-conf-dir` (nilai bawaannya `/etc/cni/net.d`). +* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan` kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`. +* `--network-plugin-mtu=9001` menentukan MTU yang akan digunakan, saat ini hanya digunakan oleh _plugin_ jaringan `kubenet`. + +{{% /capture %}} + +{{% capture whatsnext %}} + +{{% /capture %}} diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md new file mode 100644 index 0000000000..c68a207edf --- /dev/null +++ b/content/id/docs/concepts/workloads/controllers/daemonset.md @@ -0,0 +1,236 @@ +--- +title: DaemonSet +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +DaemonSet memastikan semua atau sebagian Node memiliki salinan sebuah Pod. +Ketika Node baru ditambahkan ke klaster, Pod ditambahkan ke Node tersebut. +Ketika Node dihapus dari klaster, Pod akan dibersihkan oleh _garbage collector_. +Menghapus DaemonSet akan menghapus semua Pod yang ia buat. + +Beberapa penggunaan umum DaemonSet, yaitu: + +- menjalankan _daemon_ penyimpanan di klaster, seperti `glusterd`, `ceph`, di + setiap Node. +- menjalankan _daemon_ pengumpulan log di semua Node, seperti `fluentd` atau + `logstash`. +- menjalankan _daemon_ pemantauan Node di setiap Node, seperti [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` atau [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/). + +Dalam kasus sederhana, satu DaemonSet, mencakup semua Node, akan digunakan untuk +setiap jenis _daemon_. Pengaturan yang lebih rumit bisa saja menggunakan lebih +dari satu DaemonSet untuk satu jenis _daemon_, tapi dengan _flag_ dan/atau +permintaan cpu/memori yang berbeda untuk jenis _hardware_ yang berbeda. + +{{% /capture %}} + + +{{% capture body %}} + +## Menulis Spek DaemonSet + +### Buat DaemonSet + +Kamu bisa definisikan DaemonSet dalam berkas YAML. Contohnya, berkas +`daemonset.yaml` di bawah mendefinisikan DaemonSet yang menjalankan _image_ Docker +fluentd-elasticsearch: + +{{< codenew file="controllers/daemonset.yaml" >}} + +* Buat DaemonSet berdasarkan berkas YAML: +``` +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml +``` + +### _Field_ Wajib + +Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_ +`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/), +[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/). + +DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Templat Pod + +`.spec.template` adalah salah satu _field_ wajib di dalam `.spec`. + +`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#templat-pod). Skemanya benar-benar sama dengan [Pod](/id/docs/concepts/workloads/pods/pod/), kecuali bagian bahwa ia bersarang/_nested_ dan tidak memiliki `apiVersion` atau `kind`. + +Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus +menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)). + +Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`. +DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer +keluar/berhenti atau terjadi _crash_. + +### Selektor Pod + +_Field_ `.spec.selector` adalah selektor Pod. Cara kerjanya sama dengan `.spec.selector` pada [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). + +Pada Kubernetes 1.8, kamu harus menspesifikasikan selektor Pod yang cocok dengan label pada `.spec.template`. +Selektor Pod tidak akan lagi diberi nilai _default_ ketika dibiarkan kosong. Nilai _default_ selektor tidak +cocok dengan `kubectl apply`. Juga, sesudah DaemonSet dibuat, `.spec.selector` tidak dapat diubah. +Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan membingungkan pengguna. + +Objek `.spec.selector` memiliki dua _field_: + +* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). +* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih + dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan + hubungan antara _key_ dan _value_. + +Ketika keduanya dispesifikasikan hasilnya diperoleh dari operasi AND. + +Jika `.spec.selector` dispesifikasikan, nilainya harus cocok dengan `.spec.template.metadata.labels`. Konfigurasi yang tidak cocok akan ditolak oleh API. + +Selain itu kamu tidak seharusnya membuat Pod apapun yang labelnya cocok dengan +selektor tersebut, entah secara langsung, via DaemonSet lain, atau via _workload resource_ lain seperti ReplicaSet. +Jika kamu coba buat, {{< glossary_tooltip term_id="controller" >}} DaemonSet akan +berpikir bahwa Pod tersebut dibuat olehnya. Kubernetes tidak akan menghentikan +kamu melakukannya. Contoh kasus di mana kamu mungkin melakukan ini dengan +membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_. + +### Menjalankan Pod di Sebagian Node + +Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan +membuat Pod pada Node yang cocok dengan [selektor +Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, +maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/). +Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan +membuat Pod pada semua Node. + +## Bagaimana Pod Daemon Dijadwalkan + +### Dijadwalkan oleh _default scheduler_ + +{{< feature-state state="stable" for-kubernetes-version="1.17" >}} + +DaemonSet memastikan bahwa semua Node yang memenuhi syarat menjalankan salinan +Pod. Normalnya, Node yang menjalankan Pod dipilih oleh _scheduler_ Kubernetes. +Namun, Pod DaemonSet dibuat dan dijadwalkan oleh _controller_ DaemonSet. Hal ini +mendatangkan masalah-masalah berikut: + + * Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat + dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini + membingungkan untuk pengguna. + * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/) + ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan, + _controller_ DaemonSet akan membuat keputusan penjadwalan tanpa + memperhitungkan prioritas Pod dan _preemption_. + +`ScheduleDaemonSetPods` mengizinkan kamu untuk menjadwalkan DaemonSet +menggunakan _default scheduler_ daripada _controller_ DaemonSet, dengan +menambahkan syarat `NodeAffinity` pada Pod DaemonSet daripada syarat +`.spec.nodeName`. Kemudian, _default scheduler_ digunakan untuk mengikat Pod ke +host target. Jika afinitas Node dari Pod DaemonSet sudah ada, maka ini +akan diganti. _Controller DaemonSet_ hanya akan melakukan operasi-operasi ini +ketika membuat atau mengubah Pod DaemonSet, dan tidak ada perubahan yang terjadi +pada `spec.template` DaemonSet. + +```yaml +nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchFields: + - key: metadata.name + operator: In + values: + - target-host-name +``` + +Sebagai tambahan, _toleration_ `node.kubernetes.io/unschedulable:NoSchedule` +ditambahkan secara otomatis pada Pod DaemonSet. _Default scheduler_ akan +mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet. + +### _Taint_ dan _Toleration_ + +Meskipun Pod Daemon menghormati +[taint dan toleration](/docs/concepts/configuration/taint-and-toleration), +_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai +dengan fitur yang bersangkutan. + +| _Toleration Key_ | _Effect_ | Versi | Deskripsi | +| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------------------------------------------------------ | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Pod DaemonSet tidak akan menjadi _evicted_ ketika ada masalah Node seperti partisi jaringan. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Pod DaemonSet tidak akan menjadi _evicted_ ketika ada masalah Node seperti partisi jaringan. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Pod DaemonSet mentoleransi atribut `unschedulable` _default scheduler_. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Pod DaemonSet yang menggunakan jaringan host mentoleransi atribut `network-unavailable` _default scheduler_. | + + + +## Berkomunikasi dengan Pod Daemon + +Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam DaemonSet, yaitu: + +- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain, + contohnya _stats database_. Pod ini tidak memiliki klien. +- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi. +- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama, + dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS. +- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada + Node random. (Tidak ada cara mengakses spesifik Node) + +## Melakukan Pembaruan DaemonSet + +Jika label Node berubah, DaemonSet akan menambahkan Pod ke Node cocok yang baru dan menghapus Pod dari +Node tidak cocok yang baru. + +Kamu bisa mengubah Pod yang dibuat DaemonSet. Namun, Pod tidak membolehkan perubahan semua _field_. +Perlu diingat, _controller_ DaemonSet akan menggunakan templat yang asli di waktu selanjutnya +Node baru (bahkan dengan nama yang sama) dibuat. + +Kamu bisa menghapus DaemonSet. Jika kamu spesifikasikan `--cascade=false` dengan `kubectl`, maka +Pod akan dibiarkan pada Node. Jika kamu pada waktu kemudian membuat DaemonSet baru dengan selektor +yang sama, DaemonSet yang baru akan mengadopsi Pod yang sudah ada. Jika ada Pod yang perlu diganti, +DaemonSet akan mengganti sesuai dengan `updateStrategy`. + +Kamu bisa [melakukan rolling update](/docs/tasks/manage-daemon/update-daemon-set/) pada DaemonSet. + +## Alternatif DaemonSet + +### _Init Scripts_ + +Kamu mungkin menjalankan proses _daemon_ dengan cara menjalankan mereka langsung pada Node (e.g. +menggunakan `init`, `upstartd`, atau `systemd`). Tidak ada salahnya seperti itu. Namun, ada beberapa +keuntungan menjalankan proses _daemon_ via DaemonSet. + +- Kemampuan memantau dan mengatur log _daemon_ dengan cara yang sama dengan aplikasi. +- Bahasa dan alat Konfigurasi yang sama (e.g. Templat Pod, `kubectl`) untuk _daemon_ dan aplikasi. +- Menjalankan _daemon_ dalam kontainer dengan batasan _resource_ meningkatkan isolasi antar _daemon_ dari + kontainer aplikasi. Namun, hal ini juga bisa didapat dengan menjalankan _daemon_ dalam kontainer tapi + tanpa Pod (e.g. dijalankan langsung via Docker). + +### Pod Polosan + +Dimungkinkan untuk membuat Pod langsung dengan menspesifikasikan Node mana untuk dijalankan. Namun, +DaemonSet akan menggantikan Pod yang untuk suatu alasan dihapus atau dihentikan, seperti pada saat +kerusakan Node atau pemeliharaan Node yang mengganggu seperti pembaruan _kernel_. Oleh karena itu, kamu +perlu menggunakan DaemonSet daripada membuat Pod satu per satu. + +### Pod Statis + +Dimungkinkan untuk membuat Pod dengan menulis sebuah berkas ke direktori tertentu yang di-_watch_ oleh Kubelet. +Pod ini disebut dengan istilah [Pod statis](/docs/concepts/cluster-administration/static-pod/). +Berbeda dengan DaemonSet, Pod statis tidak dapat dikelola menggunakan kubectl atau klien API Kubernetes +yang lain. Pod statis tidak bergantung kepada apiserver, membuat Pod statis berguna pada kasus-kasus +_bootstrapping_ klaster. + + +### Deployment + +DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka +sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web, +peladen penyimpanan) + +Gunakan Deployment untuk layanan _stateless_, seperti _frontend_, di mana proses _scaling_ naik +dan turun jumlah replika dan _rolling update_ lebih penting daripada mengatur secara tepat di +host mana Pod berjalan. Gunakan DaemonSet ketika penting untuk satu salinan Pod +selalu berjalan di semua atau sebagian host, dan ketika Pod perlu berjalan +sebelum Pod lainnya. + +{{% /capture %}} diff --git a/content/id/docs/reference/glossary/etcd.md b/content/id/docs/reference/glossary/etcd.md index dc09267a21..957c9a0062 100644 --- a/content/id/docs/reference/glossary/etcd.md +++ b/content/id/docs/reference/glossary/etcd.md @@ -15,4 +15,4 @@ tags: -Selalu perhatikan mekanisme untuk mem-backup data etcd pada klaster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat [dokumentasi etcd](https://github.com/coreos/etcd/blob/master/Documentation/docs.md). +Selalu perhatikan mekanisme untuk mem-backup data etcd pada klaster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat [dokumentasi etcd](https://etcd.io/docs). diff --git a/content/id/examples/controllers/daemonset.yaml b/content/id/examples/controllers/daemonset.yaml new file mode 100644 index 0000000000..1bfa082833 --- /dev/null +++ b/content/id/examples/controllers/daemonset.yaml @@ -0,0 +1,42 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + resources: + limits: + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/ja/_index.html b/content/ja/_index.html index f8f2bdf54d..e458e11754 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -1,8 +1,9 @@ --- -title: "Production-Grade Container Orchestration" +title: "ăƒ—ăƒ­ăƒ€ă‚Żă‚·ăƒ§ăƒłă‚°ăƒŹăƒŒăƒ‰ăźă‚łăƒłăƒ†ăƒŠçźĄç†ćŸș盀" abstract: "è‡Șć‹•ćŒ–ă•ă‚ŒăŸă‚łăƒłăƒ†ăƒŠăźăƒ‡ăƒ—ăƒ­ă‚€ăƒ»ă‚čă‚±ăƒŒăƒ«ăƒ»çźĄç†" cid: home --- +{{< announcement >}} {{< deprecationwarning >}} @@ -44,12 +45,12 @@ Kubernetesはă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čăȘぼで、ă‚Șンプレミă‚čやパブăƒȘッ


- 2019ćčŽ5æœˆăźKubeCon ăƒăƒ«ă‚»ăƒ­ăƒŠă«ć‚ćŠ ă™ă‚‹ + 2020ćčŽ4æœˆăźKubeCon ケムă‚čăƒ†ăƒ«ăƒ€ăƒ ă«ć‚ćŠ ă™ă‚‹



- 2019ćčŽ6æœˆăźKubeCon äžŠæ”·ă«ć‚ćŠ ă™ă‚‹ + 2020ćčŽ7æœˆăźKubeCon äžŠæ”·ă«ć‚ćŠ ă™ă‚‹
diff --git a/content/ja/case-studies/appdirect/index.html b/content/ja/case-studies/appdirect/index.html index 687560aee7..276a174752 100644 --- a/content/ja/case-studies/appdirect/index.html +++ b/content/ja/case-studies/appdirect/index.html @@ -30,7 +30,7 @@ quote: > ăăźăŸă‚ă€æäŸ›ăŸă§ăźăƒ‘ă‚€ăƒ—ăƒ©ă‚€ăƒłă«ăƒœăƒˆăƒ«ăƒăƒƒă‚ŻăŒă‚ăŁăŸăźă§ă™ă€‚ă€ ă“ă‚ŒăšćŒæ™‚ă«ă€ă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ăƒăƒŒăƒ ăŒć€§ăăăȘăŁăŠă„ăă€ăăźæˆé•·ă‚’ćŸŒæŠŒă—ă—ćŠ é€Ÿă™ă‚‹äžŠă§ă‚‚ă€ă‚ˆă‚Šè‰Żă„ă‚€ăƒłăƒ•ăƒ©ăŒćż…èŠă§ă‚ă‚‹ă“ăšă«ćŒç€ŸăŻæ°—ă„ă„ăŸăźă§ă™ă€‚

ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒł

LacerteăŻèš€ă„ăŸă™ă€‚ă€Œç§ăźă‚ąă‚€ăƒ‡ă‚ąăŻă€ăƒăƒŒăƒ ăŒă‚”ăƒŒăƒ“ă‚čă‚’ă‚‚ăŁăšé«˜é€Ÿă«ăƒ‡ăƒ—ăƒ­ă‚€ă§ăă‚‹ç’°ćąƒă‚’äœœă‚ă†ăœă€ăšă„ă†ă‚‚ăźă§ă™ă€‚ăă†ă™ă‚Œă°ćœŒă‚‰ă‚‚ă€Žăă†ă ă­ă€ăƒąăƒŽăƒȘă‚čはもうć»șどたくăȘă„ă—ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă—ăŸă„ă‚ˆă€ăšèš€ă†ă§ă—ă‚‡ă†ă€‚ă€ -ćœŒă‚‰ăŻă€2016ćčŽćˆă‚Kubernetes ăźæŽĄç”šă‚’æ±șćźšă™ă‚‹ă«ă‚ăŸă‚Šă€ä»–ăźă„ăă€ă‹ăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’èȘżæŸ»ăƒ»æ€œèšŽă—ă€ăƒ—ăƒ­ăƒˆă‚żă‚€ăƒ—ă‚’äœœă‚ŠăŸă—ăŸă€‚ LacerteăźăƒăƒŒăƒ ăŻă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăžăźç›ŁèŠ–ăźăŸă‚ă«Prometheus +ćœŒă‚‰ăŻă€2016ćčŽćˆă‚Kubernetes ăźæŽĄç”šă‚’æ±șćźšă™ă‚‹ă«ă‚ăŸă‚Šă€ä»–ăźă„ăă€ă‹ăźæŠ€èĄ“ă‚’èȘżæŸ»ăƒ»æ€œèšŽă—ă€ăƒ—ăƒ­ăƒˆă‚żă‚€ăƒ—ă‚’äœœă‚ŠăŸă—ăŸă€‚ LacerteăźăƒăƒŒăƒ ăŻă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăžăźç›ŁèŠ–ăźăŸă‚ă«Prometheus ヱニタăƒȘăƒłă‚°ăƒ„ăƒŒăƒ«ă‚’ç”±ćˆă—ăŸă—ăŸă€‚ă“ăźæŹĄă«ă‚ă‚‹ăźăŻăƒˆăƒŹăƒŒă‚·ăƒłă‚°ă§ă™ă€‚ä»Šă‚„AppDirectăŻæœŹç•Ș環汃で50ä»„äžŠăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚č、15たKubernetesă‚Żăƒ©ă‚čă‚żăƒŒă‚’AWS 侊や侖界侭ぼă‚Șンプレミă‚čç’°ćąƒă§ć±•é–‹ă—ăŠă„ăŸă™ă€‚

ă‚€ăƒłăƒ‘ă‚Żăƒˆ

Kubernetesăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€ă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ăƒăƒŒăƒ ăźă“ă“æ•°ćčŽăź10ć€æˆé•·ă‚’ćŸŒæŠŒă—ă—ăŠăăŸă—ăŸă€‚ ćœŒă‚‰ăŒç¶™ç¶šçš„ă«æ©ŸèƒœèżœćŠ ă—ăŠă„ă‚‹ăšă„ă†äș‹ćźŸăšç›žăŸăŁăŠă€Œă“ăźæ–°ăŸăȘă‚€ăƒłăƒ•ăƒ©ăŒăȘă‘ă‚Œă°ă€æˆ‘ă€…ăŻć€§ćč…ăȘă‚čăƒ­ăƒŒăƒ€ă‚Šăƒłă‚’ćŒ·ă„ă‚‰ă‚ŒăŠă„ăŸăšæ€ă„ăŸă™ă€ăšă€Lacerteæ°ăŻèż°ăčăŠă„ăŸă™ă€‚Kubernetesăšă‚”ăƒŒăƒ“ă‚čćŒ–ăžç§»èĄŒă—ăŠă„ăă“ăšăŻă€SCPă‚łăƒžăƒłăƒ‰ă‚’ç”šă„ăŸă€ă‚«ă‚čă‚żăƒ ăƒĄă‚€ăƒ‰ă§äžćź‰ćźšăȘă‚·ă‚§ăƒ«ă‚čクăƒȘăƒ—ăƒˆăžăźäŸć­˜æ€§ă‚’ćŒ±ă‚ă€éžćžžă«é«˜é€Ÿă«ăȘăŁăŸă“ăšă‚’æ„ć‘łă—ăŠă„ăŸă—ăŸă€‚ æ–°ă—ă„ăƒăƒŒă‚žăƒ§ăƒłă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹æ™‚é–“ăŻ4æ™‚é–“ă‹ă‚‰æ•°ćˆ†é–“ă«çŸ­çžźă•ă‚ŒăŸă—ăŸă€‚ @@ -51,7 +51,7 @@ quote: >
ă€Œæ­Łă—ă„ă‚żă‚€ăƒŸăƒłă‚°ă§æ­Łă—ă„ćˆ€æ–­ăŒă§ăăŸă—ăŸă€‚Kubernetesăšă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–æŠ€èĄ“ăŻă€ă„ăŸă‚„ăƒ‡ăƒ•ă‚Ąă‚Żăƒˆăźă‚šă‚łă‚·ă‚čテムべみăȘă•ă‚ŒăŠă„ăŸă™ă€‚ă‚čă‚±ăƒŒăƒ«ă‚ąă‚Šăƒˆă—ăŠă„ăäž­ă§ç›Žéąă™ă‚‹æ–°ăŸăȘé›ŁéĄŒă«ć–ă‚Šç”„ă‚€ă«ăŻă©ă“ă«æłšćŠ›ă™ăčăă‹ă€ç§ăŸăĄăŻă‚ă‹ăŁăŠă„ăŸă™ă€‚ă“ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăƒŒăŻăšăŠă‚‚æŽ»ç™șă§ă€ćœ“ç€Ÿăźć„Ș秀ăȘăƒăƒŒăƒ ă‚’ă™ă°ă‚‰ă—ăèŁœćźŒă—ăŠăă‚ŒăŠă„ăŸă™ă€‚ă€

- AppDirect ă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąé–‹ç™șè€…ă€€Alexandre Gervais
-
LacerteăŻćœ“ćˆă‹ă‚‰èš€ăŁăŠă„ăŸă—ăŸă€‚ă€Œç§ăźă‚ąă‚€ăƒ‡ă‚ąăŻă€ăƒăƒŒăƒ ăŒă‚”ăƒŒăƒ“ă‚čă‚’ă‚‚ăŁăšé«˜é€Ÿă«ăƒ‡ăƒ—ăƒ­ă‚€ă§ăă‚‹ç’°ćąƒă‚’äœœă‚ă†ă€ăšă„ă†ă‚‚ăźă§ă™ă€‚ăă†ă™ă‚Œă°ćœŒă‚‰ă‚‚ă“ă†èš€ă†ă§ă—ă‚‡ă†ă€Žăă†ă ă‚ˆă€ăƒąăƒŽăƒȘă‚čをć»șどるăȘんどもうしたくăȘă„ă—ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă—ăŸă„ă‚“ă ă€ăšă€(Lacerteは2019ćčŽă«ćŒç€Ÿă‚’退瀟)。

Lacerteăźă‚°ăƒ«ăƒŒăƒ—ăŻé‹ç”šăƒăƒŒăƒ ăšé€Łæșă™ă‚‹ă“ăšă§ćŒç€Ÿăź AWSăźă‚€ăƒłăƒ•ăƒ©ă«ă‚ˆă‚Šć€šăă‚ąă‚Żă‚»ă‚čă—ă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ă™ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ăă—ăŠă€ă„ăă€ă‹ăźă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăźăƒ—ăƒ­ăƒˆă‚żă‚€ăƒ—ă‚’äœœă‚Šć§‹ă‚ăŸăźă§ă™ă€‚ă€Œćœ“æ™‚ă‚’æŒŻă‚Šèż”ă‚‹ăšă€KubernetesăŻăĄă‚‡ăŁăšă‚ąăƒłăƒ€ăƒŒă‚°ăƒ©ă‚Šăƒłăƒ‰ăšă„ă†ă‹ă€ăă‚Œă»ă©çŸ„ă‚‰ă‚ŒăŠă„ăȘă‹ăŁăŸă‚ˆă†ă«æ€ă„ăŸă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€Œă—ă‹ă—ă€ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăƒŒă‚„Pull requestăźæ•°ă€GitHub侊でぼă‚čăƒ”ăƒŒăƒ‰ăȘă©ă‚’ă‚ˆăèŠ‹ăŠăżă‚‹ăšć‹ąă„ăŒćą—ă—ăŠăăŠă„ă‚‹ă“ăšăŒă‚ă‹ă‚ŠăŸă—ăŸă€‚ä»–ăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚ˆă‚Šă‚‚çźĄç†ăŒăŻă‚‹ă‹ă«ç°Ąć˜ă§ă‚ă‚‹ă“ăšă‚‚ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€ćœŒă‚‰ăŻă€Kubernetes侊で Chef やTerraform ă«ă‚ˆă‚‹ăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’ç”šă„ăȘăŒă‚‰æœ€ćˆăźă„ăă€ă‹ăźă‚”ăƒŒăƒ“ă‚čを開ç™șă—ăŸă—ăŸă€‚ăăźćŸŒă•ă‚‰ă«ă‚”ăƒŒăƒ“ă‚čも、è‡Șć‹•ćŒ–ă•ă‚Œă‚‹ăšă“ă‚ă‚‚ćą—ăˆăŸă—ăŸă€‚ă€ŒéŸ“ć›œă€ă‚ȘăƒŒă‚čトラăƒȘă‚ąă€ăƒ‰ă‚€ăƒ„ă€ăă—ăŠă‚ąăƒĄăƒȘă‚«ă€ç§ăŸăĄăźă‚Żăƒ©ă‚čă‚żăƒŒăŻäž–ç•Œäž­ă«ă‚ă‚ŠăŸă™ă€‚ă€ăšLacerteăŻèš€ă„ăŸă™ă€‚ă€Œè‡Șć‹•ćŒ–ăŻç§ăŸăĄă«ăšăŁăŠæ„”ă‚ăŠé‡èŠă§ă™ă€‚ă€ä»ŠćœŒă‚‰ăŻć€§éƒšćˆ†ă§Kopsă‚’äœżăŁăŠă„ăŠă€ă„ăă€ă‹ăźă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă‹ă‚‰æäŸ›ă•ă‚Œă‚‹ăƒžăƒăƒŒă‚žăƒ‰Kubernetesă‚”ăƒŒăƒ“ă‚čă‚‚èŠ–é‡Žă«ć…„ă‚ŒăŠă„ă‚ŒăŠă„ăŸă™ă€‚

ä»Šă‚‚ăƒąăƒŽăƒȘă‚čăŻć­˜ćœšă—ăŠăŻă„ăŸă™ăŒă€ă‚łăƒŸăƒƒăƒˆă‚„æ©ŸèƒœăŻă©ă‚“ă©ă‚“ć°‘ăȘくăȘăŁăŠăăŠă„ăŸă™ă€‚ă‚ă‚‰ă‚†ă‚‹ăƒăƒŒăƒ ăŒă“ăźæ–°ăŸăȘă‚€ăƒłăƒ•ăƒ©äžŠă§ăƒ‡ăƒ—ăƒ­ă‚€ă—ăŠă„ăŠă€ăă‚Œă‚‰ăŻă‚”ăƒŒăƒ“ă‚čăšă—ăŠæäŸ›ă•ă‚Œă‚‹ăźăŒäž€èˆŹçš„ă§ă™ă€‚ä»Šă‚„AppDirectăŻæœŹç•Ș環汃で50ä»„äžŠăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚č、15たKubernetesă‚Żăƒ©ă‚čă‚żăƒŒă‚’AWS侊や侖界侭ぼă‚Șンプレミă‚čç’°ćąƒă§ć±•é–‹ă—ăŠă„ăŸă™ă€‚

Kubernetesăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒăƒ‡ăƒ—ăƒ­ă‚€æ™‚é–“ă«éžćžžă«ć€§ăăȘă‚€ăƒłăƒ‘ă‚Żăƒˆă‚’äžŽăˆăŸă“ăšă‹ă‚‰ă€LacerteăźæˆŠç•„ăŒç©¶æ„”çš„ă«æ©Ÿèƒœă—ăŸă—ăŸă€‚ă‚«ă‚čă‚żăƒ ăƒĄă‚€ăƒ‰ă§äžćź‰ćźšă ăŁăŸă€SCPă‚łăƒžăƒłăƒ‰ă‚’ç”šă„ăŸă‚·ă‚§ăƒ«ă‚čクăƒȘăƒ—ăƒˆă«ćŻŸă™ă‚‹äŸć­˜æ€§ă‚’ćŒ±ă‚ă‚‹ă“ăšă§ă€æ–°ă—ă„ăƒăƒŒă‚žăƒ§ăƒłă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹æ™‚é–“ăŻ4æ™‚é–“ă‹ă‚‰æ•°ćˆ†ă«ăŸă§çŸ­çžźă•ă‚Œă‚‹ă‚ˆă†ă«ăȘăŁăŸăźă§ă™ă€‚ă“ă†ă„ăŁăŸă“ăšă«ćŠ ăˆćŒç€ŸăŻă€é–‹ç™șè€…ăŸăĄăŒè‡Șă‚‰ăźă‚”ăƒŒăƒ“ă‚čăšă—ăŠä»•ç«‹ăŠäžŠă’ă‚‹ă‚ˆă†ă€æ•°ć€šăăźćŠȘćŠ›ă‚’ă—ăŠăăŸă—ăŸă€‚ă€Œæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čを構めるたに、 Jiraăźăƒă‚±ăƒƒăƒˆă‚„ä»–ăźăƒăƒŒăƒ ăšăźăƒŸăƒŒăƒ†ă‚Łăƒłă‚°ăŻă‚‚ăŻă‚„ćż…èŠăȘいぼです」べLacerteăŻèš€ă„ăŸă™ă€‚ä»„ć‰ă€é€±ă‚ăŸă‚Š1〜30ă ăŁăŸćŒç€Ÿăźăƒ‡ăƒ—ăƒ­ă‚€æ•°ăŻă€ă„ăŸă‚„é€±1,600ăƒ‡ăƒ—ăƒ­ă‚€ă«ăŸă§ăȘăŁăŠă„ăŸă™ă€‚ +
LacerteăŻćœ“ćˆă‹ă‚‰èš€ăŁăŠă„ăŸă—ăŸă€‚ă€Œç§ăźă‚ąă‚€ăƒ‡ă‚ąăŻă€ăƒăƒŒăƒ ăŒă‚”ăƒŒăƒ“ă‚čă‚’ă‚‚ăŁăšé«˜é€Ÿă«ăƒ‡ăƒ—ăƒ­ă‚€ă§ăă‚‹ç’°ćąƒă‚’äœœă‚ă†ă€ăšă„ă†ă‚‚ăźă§ă™ă€‚ăă†ă™ă‚Œă°ćœŒă‚‰ă‚‚ă“ă†èš€ă†ă§ă—ă‚‡ă†ă€Žăă†ă ă‚ˆă€ăƒąăƒŽăƒȘă‚čをć»șどるăȘんどもうしたくăȘă„ă—ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă—ăŸă„ă‚“ă ă€ăšă€(Lacerteは2019ćčŽă«ćŒç€Ÿă‚’退瀟)。

Lacerteăźă‚°ăƒ«ăƒŒăƒ—ăŻé‹ç”šăƒăƒŒăƒ ăšé€Łæșă™ă‚‹ă“ăšă§ćŒç€Ÿăź AWSăźă‚€ăƒłăƒ•ăƒ©ă«ă‚ˆă‚Šć€šăă‚ąă‚Żă‚»ă‚čă—ă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ă™ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ăă—ăŠă€ă„ăă€ă‹ăźă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłæŠ€èĄ“ăźăƒ—ăƒ­ăƒˆă‚żă‚€ăƒ—ă‚’äœœă‚Šć§‹ă‚ăŸăźă§ă™ă€‚ă€Œćœ“æ™‚ă‚’æŒŻă‚Šèż”ă‚‹ăšă€KubernetesăŻăĄă‚‡ăŁăšă‚ąăƒłăƒ€ăƒŒă‚°ăƒ©ă‚Šăƒłăƒ‰ăšă„ă†ă‹ă€ăă‚Œă»ă©çŸ„ă‚‰ă‚ŒăŠă„ăȘă‹ăŁăŸă‚ˆă†ă«æ€ă„ăŸă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€Œă—ă‹ă—ă€ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăƒŒă‚„Pull requestăźæ•°ă€GitHub侊でぼă‚čăƒ”ăƒŒăƒ‰ăȘă©ă‚’ă‚ˆăèŠ‹ăŠăżă‚‹ăšć‹ąă„ăŒćą—ă—ăŠăăŠă„ă‚‹ă“ăšăŒă‚ă‹ă‚ŠăŸă—ăŸă€‚ä»–ăźæŠ€èĄ“ă‚ˆă‚Šă‚‚çźĄç†ăŒăŻă‚‹ă‹ă«ç°Ąć˜ă§ă‚ă‚‹ă“ăšă‚‚ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€ćœŒă‚‰ăŻă€Kubernetes侊で Chef やTerraform ă«ă‚ˆă‚‹ăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’ç”šă„ăȘăŒă‚‰æœ€ćˆăźă„ăă€ă‹ăźă‚”ăƒŒăƒ“ă‚čを開ç™șă—ăŸă—ăŸă€‚ăăźćŸŒă•ă‚‰ă«ă‚”ăƒŒăƒ“ă‚čも、è‡Șć‹•ćŒ–ă•ă‚Œă‚‹ăšă“ă‚ă‚‚ćą—ăˆăŸă—ăŸă€‚ă€ŒéŸ“ć›œă€ă‚ȘăƒŒă‚čトラăƒȘă‚ąă€ăƒ‰ă‚€ăƒ„ă€ăă—ăŠă‚ąăƒĄăƒȘă‚«ă€ç§ăŸăĄăźă‚Żăƒ©ă‚čă‚żăƒŒăŻäž–ç•Œäž­ă«ă‚ă‚ŠăŸă™ă€‚ă€ăšLacerteăŻèš€ă„ăŸă™ă€‚ă€Œè‡Șć‹•ćŒ–ăŻç§ăŸăĄă«ăšăŁăŠæ„”ă‚ăŠé‡èŠă§ă™ă€‚ă€ä»ŠćœŒă‚‰ăŻć€§éƒšćˆ†ă§Kopsă‚’äœżăŁăŠă„ăŠă€ă„ăă€ă‹ăźă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă‹ă‚‰æäŸ›ă•ă‚Œă‚‹ăƒžăƒăƒŒă‚žăƒ‰Kubernetesă‚”ăƒŒăƒ“ă‚čă‚‚èŠ–é‡Žă«ć…„ă‚ŒăŠă„ă‚ŒăŠă„ăŸă™ă€‚

ä»Šă‚‚ăƒąăƒŽăƒȘă‚čăŻć­˜ćœšă—ăŠăŻă„ăŸă™ăŒă€ă‚łăƒŸăƒƒăƒˆă‚„æ©ŸèƒœăŻă©ă‚“ă©ă‚“ć°‘ăȘくăȘăŁăŠăăŠă„ăŸă™ă€‚ă‚ă‚‰ă‚†ă‚‹ăƒăƒŒăƒ ăŒă“ăźæ–°ăŸăȘă‚€ăƒłăƒ•ăƒ©äžŠă§ăƒ‡ăƒ—ăƒ­ă‚€ă—ăŠă„ăŠă€ăă‚Œă‚‰ăŻă‚”ăƒŒăƒ“ă‚čăšă—ăŠæäŸ›ă•ă‚Œă‚‹ăźăŒäž€èˆŹçš„ă§ă™ă€‚ä»Šă‚„AppDirectăŻæœŹç•Ș環汃で50ä»„äžŠăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚č、15たKubernetesă‚Żăƒ©ă‚čă‚żăƒŒă‚’AWS侊や侖界侭ぼă‚Șンプレミă‚čç’°ćąƒă§ć±•é–‹ă—ăŠă„ăŸă™ă€‚

Kubernetesăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒăƒ‡ăƒ—ăƒ­ă‚€æ™‚é–“ă«éžćžžă«ć€§ăăȘă‚€ăƒłăƒ‘ă‚Żăƒˆă‚’äžŽăˆăŸă“ăšă‹ă‚‰ă€LacerteăźæˆŠç•„ăŒç©¶æ„”çš„ă«æ©Ÿèƒœă—ăŸă—ăŸă€‚ă‚«ă‚čă‚żăƒ ăƒĄă‚€ăƒ‰ă§äžćź‰ćźšă ăŁăŸă€SCPă‚łăƒžăƒłăƒ‰ă‚’ç”šă„ăŸă‚·ă‚§ăƒ«ă‚čクăƒȘăƒ—ăƒˆă«ćŻŸă™ă‚‹äŸć­˜æ€§ă‚’ćŒ±ă‚ă‚‹ă“ăšă§ă€æ–°ă—ă„ăƒăƒŒă‚žăƒ§ăƒłă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹æ™‚é–“ăŻ4æ™‚é–“ă‹ă‚‰æ•°ćˆ†ă«ăŸă§çŸ­çžźă•ă‚Œă‚‹ă‚ˆă†ă«ăȘăŁăŸăźă§ă™ă€‚ă“ă†ă„ăŁăŸă“ăšă«ćŠ ăˆćŒç€ŸăŻă€é–‹ç™șè€…ăŸăĄăŒè‡Șă‚‰ăźă‚”ăƒŒăƒ“ă‚čăšă—ăŠä»•ç«‹ăŠäžŠă’ă‚‹ă‚ˆă†ă€æ•°ć€šăăźćŠȘćŠ›ă‚’ă—ăŠăăŸă—ăŸă€‚ă€Œæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čを構めるたに、 Jiraăźăƒă‚±ăƒƒăƒˆă‚„ä»–ăźăƒăƒŒăƒ ăšăźăƒŸăƒŒăƒ†ă‚Łăƒłă‚°ăŻă‚‚ăŻă‚„ćż…èŠăȘいぼです」べLacerteăŻèš€ă„ăŸă™ă€‚ä»„ć‰ă€é€±ă‚ăŸă‚Š1〜30ă ăŁăŸćŒç€Ÿăźăƒ‡ăƒ—ăƒ­ă‚€æ•°ăŻă€ă„ăŸă‚„é€±1,600ăƒ‡ăƒ—ăƒ­ă‚€ă«ăŸă§ăȘăŁăŠă„ăŸă™ă€‚
diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html index 561c47e0d3..4c288aa97a 100644 --- a/content/ja/case-studies/chinaunicom/index.html +++ b/content/ja/case-studies/chinaunicom/index.html @@ -9,7 +9,7 @@ logo: chinaunicom_featured_logo.png featured: true weight: 1 quote: > - KubernetesăŒç§ăŸăĄăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ä»Šăźăšă“ă‚ă“ă‚Œă«ä»Łă‚ă‚‹ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă‚ă‚ŠăŸă›ă‚“ă€‚ + KubernetesăŒç§ăŸăĄăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ä»Šăźăšă“ă‚ă€ă“ă‚Œă«ä»Łă‚ă‚‹æŠ€èĄ“ăŻă‚ă‚ŠăŸă›ă‚“ă€‚ ---
@@ -32,7 +32,7 @@ quote: >

ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒł

- æ€„æˆé•·ă—ă€ă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚‚æˆç†Ÿă—ăŠă„ă‚‹KubernetesはChina Unicomにずっおè‡Ș然ăȘéžæŠžăšăȘă‚ŠăŸă—ăŸă€‚ćŒç€ŸăźKubernetesćŻŸćżœă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€çŸçŠ¶ăź50ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă«ćŠ ăˆă€ă“ă‚Œă‹ă‚‰æ–°ăŸă«é–‹ç™șされるすăčどをここでホă‚čトしどいくそうです。「KubernetesăŒç§ăŸăĄăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€ăšZhangăŻă„ă„ăŸă™ă€‚ă€Œä»Šăźăšă“ă‚ă“ă‚Œă«ä»Łă‚ă‚‹ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€ăŸăŸă€China UnicomăŻăăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čăƒ•ăƒŹăƒŒăƒ ăƒŻăƒŒă‚ŻăźăŸă‚ă«ă€Istio、 Envoy、 CoreDNS、そしどFluentdă‚‚æŽ»ç”šă—ăŠă„ăŸă™ă€‚ + æ€„æˆé•·ă—ă€ă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚‚æˆç†Ÿă—ăŠă„ă‚‹KubernetesはChina Unicomにずっおè‡Ș然ăȘéžæŠžăšăȘă‚ŠăŸă—ăŸă€‚ćŒç€ŸăźKubernetesćŻŸćżœă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă§ăŻă€çŸçŠ¶ăź50ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă«ćŠ ăˆă€ă“ă‚Œă‹ă‚‰æ–°ăŸă«é–‹ç™șされるすăčどをここでホă‚čトしどいくそうです。「KubernetesăŒç§ăŸăĄăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€ăšZhangăŻă„ă„ăŸă™ă€‚ă€Œä»Šăźăšă“ă‚ă€ă“ă‚Œă«ä»Łă‚ă‚‹æŠ€èĄ“ăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€ăŸăŸă€China UnicomăŻăăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čăƒ•ăƒŹăƒŒăƒ ăƒŻăƒŒă‚ŻăźăŸă‚ă«ă€Istio、 Envoy、 CoreDNS、そしどFluentdă‚‚æŽ»ç”šă—ăŠă„ăŸă™ă€‚

ă‚€ăƒłăƒ‘ă‚Żăƒˆ

KubernetesはChina Unicomぼ運甹べ開ç™ș、価æ–čに぀いおćŠčçŽ‡ă‚’é«˜ă‚ăŠăă‚ŒăŸă—ăŸă€‚ @@ -44,7 +44,7 @@ quote: >
- 「KubernetesăŒç§é”ăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ä»Šăźăšă“ă‚ă“ă‚Œă«ä»Łă‚ă‚‹ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€ + 「KubernetesăŒç§é”ăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ä»Šăźăšă“ă‚ă€ă“ă‚Œă«ä»Łă‚ă‚‹æŠ€èĄ“ăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€
- Chengyu Zhang、 China Unicom ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“R&D ă‚°ăƒ«ăƒŒăƒ—ăƒȘăƒŒăƒ€ăƒŒ
@@ -54,7 +54,7 @@ quote: > ăăźèˆžć°èŁă§ă€ćŒç€ŸăŻ2016ćčŽä»„æ„ă€Dockerコンテナ、VMware、OpenStackă‚€ăƒłăƒ•ăƒ©ăȘă©ă‚’ç”šă„ăŠă€æ•°ćƒăźă‚”ăƒŒăƒăƒŒă‚’æŒă€ăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăƒŒă‚’è€‡æ•°é‹ç”šă—ăŠă„ăŸă™ă€‚æź‹ćż”ăȘがら、「ăƒȘă‚œăƒŒă‚čćˆ©ç”šçŽ‡ăŻç›žćŻŸçš„ă«äœŽă‹ăŁăŸă€ăšă€ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“ăźR&Déƒšé–€ăźă‚°ăƒ«ăƒŒăƒ—ăƒȘăƒŒăƒ€ăƒŒă§ă‚ă‚‹Chengyu ZhangはèȘžăŁăŠă„ăŸă™ă€‚ă€Œăă—ăŠă€ç§ăŸăĄă«ăŻäœ•ç™Ÿă‚‚ăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćŽćźčă§ăă‚‹ă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒă‚ă‚ŠăŸă›ă‚“ă§ă—ăŸă€‚ă€

- ăă“ă§æ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă€ç ”ç©¶é–‹ç™ș(R&D)ă€ăŠă‚ˆăłăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăźèČŹć‹™ă‚’æ‹…ă†ZhangăźăƒăƒŒăƒ ăŻă€ITçźĄç†ă«ăŠă‘ă‚‹ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăźæŽąçŽąă‚’ć§‹ă‚ăŸă—ăŸă€‚ä»„ć‰ăŻćźŒć…šăȘć›œć–¶äŒæ„­ă ăŁăŸChina UnicomăŻă€èż‘ćčŽBAT(Baidu、Alibaba、Tencent)およびJD.comă‹ă‚‰ăźæ°‘é–“æŠ•èł‡ă‚’ć—ă‘ă€ä»ŠăŻć•†ç”šèŁœć“ă§ăŻăȘくă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čæŠ€èĄ“ă‚’æŽ»ç”šă—ăŸç€Ÿć†…é–‹ç™șă«æłšćŠ›ă™ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă“ă†ă„ăŁăŸă“ăšă‚‚ă‚ă‚Šă€ZhangăźăƒăƒŒăƒ ăŻă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłăƒ„ăƒŒăƒ«ă‚’æŽąă—ć§‹ă‚ăŸăźă§ă™ă€‚ + ăă“ă§æ–°ă—ă„æŠ€èĄ“ă€ç ”ç©¶é–‹ç™ș(R&D)ă€ăŠă‚ˆăłăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăźèČŹć‹™ă‚’æ‹…ă†ZhangăźăƒăƒŒăƒ ăŻă€ITçźĄç†ă«ăŠă‘ă‚‹ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăźæŽąçŽąă‚’ć§‹ă‚ăŸă—ăŸă€‚ä»„ć‰ăŻćźŒć…šăȘć›œć–¶äŒæ„­ă ăŁăŸChina UnicomăŻă€èż‘ćčŽBAT(Baidu、Alibaba、Tencent)およびJD.comă‹ă‚‰ăźæ°‘é–“æŠ•èł‡ă‚’ć—ă‘ă€ä»ŠăŻć•†ç”šèŁœć“ă§ăŻăȘくă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čæŠ€èĄ“ă‚’æŽ»ç”šă—ăŸç€Ÿć†…é–‹ç™șă«æłšćŠ›ă™ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă“ă†ă„ăŁăŸă“ăšă‚‚ă‚ă‚Šă€ZhangăźăƒăƒŒăƒ ăŻă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłăƒ„ăƒŒăƒ«ă‚’æŽąă—ć§‹ă‚ăŸăźă§ă™ă€‚
@@ -67,9 +67,9 @@ quote: >
China UnicomはすでにコスずăȘるäș‹æ„­é‹ç”šă‚·ă‚čăƒ†ăƒ ă«Mesosă‚’æŽ»ç”šă—ăŠă„ăŸă—ăŸăŒă€ăƒăƒŒăƒ ă«ăšăŁăŠăŻæ–°ă—ă„ă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă«ăŻKubernetesăźéžæŠžăŒè‡Șç„¶ă ă‚ă†ăšæ„Ÿă˜ă‚‰ă‚ŒăŸăźă§ă™ă€‚ă€Œć€§ăăȘ理由は、Kubernetesă«ăŻæˆç†Ÿă—ăŸă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŒă‚ă‚‹ă€ăšă„ă†ă“ăšă§ă—ăŸă€ăšZhangăŻèš€ă„ăŸă™ă€‚ă€Œă•ă‚‰ă«KubernetesăŻéžćžžă«æ—©ă„ăƒšăƒŒă‚čă§æˆé•·ă—ăŠă„ă‚‹ă“ăšă‚‚ă‚ă‚Šă€ă•ăŸă–ăŸăȘäșșぼベă‚čăƒˆăƒ—ăƒ©ă‚Żăƒ†ă‚Łă‚čă‹ă‚‰ć€šăă‚’ć­Šă¶ă“ăšăŒă§ăă‚‹ăźă§ă™ă€‚ă€ ăŸăŸChina UnicomăŻăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čăƒ•ăƒŹăƒŒăƒ ăƒŻăƒŒă‚ŻăźăŸă‚ă«Istio、Envoy、CoreDNS、およびFluentdă‚‚äœżç”šă—ăŠă„ăŸă™ă€‚

- ćŒç€ŸăźKubernetesćŻŸćżœă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€çŸçŠ¶ăź50ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă«ćŠ ăˆă€ă“ă‚Œă‹ă‚‰æ–°ăŸă«é–‹ç™șされるすăčどをここでホă‚čトしどいくそうです。China Unicomぼ開ç™șè€…ăŸăĄăŻè‡Șèș«ăźæ‰‹ă«ă‚ˆă‚‹é–‹ç™șを省き、APIă‚’ä»‹ă™ă“ăšă§ç°Ąć˜ă«ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŒćˆ©ç”šă§ăă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă“ăźă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€ćŒç€Ÿăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăźPaaSăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă«çč‹ăŒăŁăŸ20〜30ăźă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă™ă‚‹ă“ăšă«ćŠ ăˆă€äž­ć›œć›œć†…ăź31çœă«ă‚ăŸă‚‹æ‹ ç‚čăźç€Ÿć†…ăƒŠăƒŒă‚¶ăƒŒăŸăĄăŒèĄŒă†ăƒ“ăƒƒă‚°ăƒ‡ăƒŒă‚żćˆ†æžăȘă©ă‚‚ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚

+ ćŒç€ŸăźKubernetesćŻŸćżœă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă§ăŻă€çŸçŠ¶ăź50ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă«ćŠ ăˆă€ă“ă‚Œă‹ă‚‰æ–°ăŸă«é–‹ç™șされるすăčどをここでホă‚čトしどいくそうです。China Unicomぼ開ç™șè€…ăŸăĄăŻè‡Șèș«ăźæ‰‹ă«ă‚ˆă‚‹é–‹ç™șを省き、APIă‚’ä»‹ă™ă“ăšă§ç°Ąć˜ă«æŠ€èĄ“ăŒćˆ©ç”šă§ăă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă“ăźă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€ćŒç€Ÿăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăźPaaSăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă«çč‹ăŒăŁăŸ20〜30ăźă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă™ă‚‹ă“ăšă«ćŠ ăˆă€äž­ć›œć›œć†…ăź31çœă«ă‚ăŸă‚‹æ‹ ç‚čăźç€Ÿć†…ăƒŠăƒŒă‚¶ăƒŒăŸăĄăŒèĄŒă†ăƒ“ăƒƒă‚°ăƒ‡ăƒŒă‚żćˆ†æžăȘă©ă‚‚ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚

- 「KubernetesăŒç§é”ăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ă€ăšZhangăŻă„ă„ăŸă™ă€‚ă€Œä»Šăźăšă“ă‚ă“ă‚Œă«ä»Łă‚ă‚‹ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€ + 「KubernetesăŒç§é”ăźă‚Żăƒ©ă‚Šăƒ‰ă‚€ăƒłăƒ•ăƒ©ăźç”Œéš“ć€€ă‚’äžŠă’ăŠăă‚ŒăŸă—ăŸă€‚ă€ăšZhangăŻă„ă„ăŸă™ă€‚ă€Œä»Šăźăšă“ă‚ă€ă“ă‚Œă«ä»Łă‚ă‚‹æŠ€èĄ“ăŻă‚ă‚ŠăŸă›ă‚“ă€‚ă€
@@ -87,12 +87,12 @@ quote: >
-ă€ŒäŒæ„­ăŻRancherぼようăȘäș‹æ„­è€…ăŒæäŸ›ă™ă‚‹ăƒžăƒăƒŒă‚žăƒ‰ă‚”ăƒŒăƒ“ă‚čă‚’æŽ»ç”šă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă“ă†ă„ăŁăŸăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă™ă§ă«ă‚«ă‚čă‚żăƒžă‚€ă‚șă•ă‚ŒăŠæäŸ›ă•ă‚Œă‚‹ăźă§ă€ç°Ąć˜ă«ćˆ©ç”šă™ă‚‹ă“ăšăŒă§ăă‚‹ă§ă—ă‚‡ă†ă€‚ă€

- Jie Jia、China Unicom ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“ R&D
+ă€ŒäŒæ„­ăŻRancherぼようăȘäș‹æ„­è€…ăŒæäŸ›ă™ă‚‹ăƒžăƒăƒŒă‚žăƒ‰ă‚”ăƒŒăƒ“ă‚čă‚’æŽ»ç”šă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă“ă†ă—ăŸæŠ€èĄ“ăŻă™ă§ă«ă‚«ă‚čă‚żăƒžă‚€ă‚șă•ă‚ŒăŠæäŸ›ă•ă‚Œă‚‹ăźă§ă€ç°Ąć˜ă«ćˆ©ç”šă™ă‚‹ă“ăšăŒă§ăă‚‹ă§ă—ă‚‡ă†ă€‚ă€

- Jie Jia、China Unicom ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“ R&D
- ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“ R&D ăƒăƒŒăƒ ăźäž€ć“Ąă§ă‚ă‚‹Jie JiaăŻă€ă€Œă“ăźæŠ€èĄ“ăŻæŻ”èŒƒçš„è€‡é›‘ă§ă™ăŒă€é–‹ç™șè€…ăŒæ…Łă‚Œă‚Œă°ă€æ©æ”ă‚’ă™ăčおäș«ć—ă§ăă‚‹ăźă§ăŻăȘă„ă‹ăšæ€ă„ăŸă™ă€ăšä»˜ă‘ćŠ ăˆăŠă„ăŸă™ă€‚äž€æ–čでZhangăŻă€ä»źæƒłăƒžă‚·ăƒłăƒ™ăƒŒă‚čăźă‚Żăƒ©ă‚Šăƒ‰ă§ăźç”Œéš“ă‹ă‚‰èŠ‹ă‚‹ăšă€ă€ŒKubernetesăšă“ă‚Œă‚‰ăźă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻæŻ”èŒƒçš„ă‚·ăƒłăƒ—ăƒ«ăȘたではăȘă„ă‹ă€ăšæŒ‡æ‘˜ă—ăŠă„ăŸă™ă€‚

- ă€ŒäŒæ„­ăŻ Rancher ぼようăȘäș‹æ„­è€…ăŒæäŸ›ă™ă‚‹ăƒžăƒăƒŒă‚žăƒ‰ă‚”ăƒŒăƒ“ă‚čă‚’æŽ»ç”šă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă“ă†ă„ăŁăŸăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă‚«ă‚čă‚żăƒžă‚€ă‚șăŠă•ă‚ŒăŠæäŸ›ă•ă‚Œă‚‹ăźă§ă€ç°Ąć˜ă«ćˆ©ç”šă™ă‚‹ă“ăšăŒă§ăă‚‹ă§ă—ă‚‡ă†ă€‚ă€

+ ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ æŠ€èĄ“ R&D ăƒăƒŒăƒ ăźäž€ć“Ąă§ă‚ă‚‹Jie JiaăŻă€ă€Œă“ăźæŠ€èĄ“ăŻæŻ”èŒƒçš„è€‡é›‘ă§ă™ăŒă€é–‹ç™șè€…ăŒæ…Łă‚Œă‚Œă°ă€æ©æ”ă‚’ă™ăčおäș«ć—ă§ăă‚‹ăźă§ăŻăȘă„ă‹ăšæ€ă„ăŸă™ă€ăšä»˜ă‘ćŠ ăˆăŠă„ăŸă™ă€‚äž€æ–čでZhangăŻă€ä»źæƒłăƒžă‚·ăƒłăƒ™ăƒŒă‚čăźă‚Żăƒ©ă‚Šăƒ‰ă§ăźç”Œéš“ă‹ă‚‰èŠ‹ă‚‹ăšă€ă€ŒKubernetesăšă“ă‚Œă‚‰ăźă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–æŠ€èĄ“ăŻæŻ”èŒƒçš„ă‚·ăƒłăƒ—ăƒ«ăȘたではăȘă„ă‹ă€ăšæŒ‡æ‘˜ă—ăŠă„ăŸă™ă€‚

+ ă€ŒäŒæ„­ăŻ Rancher ぼようăȘäș‹æ„­è€…ăŒæäŸ›ă™ă‚‹ăƒžăƒăƒŒă‚žăƒ‰ă‚”ăƒŒăƒ“ă‚čă‚’æŽ»ç”šă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă“ă†ă—ăŸæŠ€èĄ“ăŻă‚«ă‚čă‚żăƒžă‚€ă‚șă•ă‚ŒăŠæäŸ›ă•ă‚Œă‚‹ăźă§ă€ç°Ąć˜ă«ćˆ©ç”šă™ă‚‹ă“ăšăŒă§ăă‚‹ă§ă—ă‚‡ă†ă€‚ă€

ä»ŠćŸŒChina UnicomăŻăƒ“ăƒƒă‚°ăƒ‡ăƒŒă‚żăšæ©Ÿæą°ć­Šçż’ă«é‡ç‚čă‚’çœźă„ăŠă€KubernetesäžŠă§ă‚ˆă‚Šć€šăăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’é–‹ç™șă™ă‚‹ă“ăšă‚’èšˆç”»ă—ăŠă„ăŸă™ă€‚ćœŒă‚‰ăźăƒăƒŒăƒ ăŻçŻ‰ăäžŠă’ăŸă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚’ç¶™ç¶šçš„ă«æœ€é©ćŒ–ă—ăŠăŠă‚Šă€CNCFたèȘćźšKubernetesă‚łăƒłăƒ•ă‚©ăƒŒăƒžăƒłă‚čăƒ—ăƒ­ă‚°ăƒ©ăƒ (Certified Kubernetes Conformance Program)ă«ć‚ćŠ ă™ă‚‹ăčăă€ăăźăŸă‚ăźé©ćˆăƒ†ă‚čト(Conformance test)ăžăźćˆæ Œă‚’ç›źæŒ‡ă—ăŠă„ăŸă™ă€‚ăŸăŸćœŒă‚‰ăŻă€ă©ă“ă‹ăźă‚żă‚€ăƒŸăƒłă‚°ă§ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă«ă‚łăƒŒăƒ‰ă‚’ă‚łăƒłăƒˆăƒȘăƒ“ăƒ„ăƒŒă‚·ăƒ§ăƒłă™ă‚‹ă“ăšă‚‚ç›źæŒ‡ă—ăŠă„ăŸă™ă€‚

diff --git a/content/ja/case-studies/nav/index.html b/content/ja/case-studies/nav/index.html new file mode 100644 index 0000000000..c9ad5ab65b --- /dev/null +++ b/content/ja/case-studies/nav/index.html @@ -0,0 +1,93 @@ +--- +title: Navă‚±ăƒŒă‚čă‚čタディ +linkTitle: Nav +case_study_styles: true +cid: caseStudies +css: /css/style_case_studies.css +logo: nav_featured_logo.png +featured: true +weight: 3 +quote: > + ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻéžćžžă«æŽ»ç™șă§ă™ă€‚ă‚ąă‚€ăƒ‡ă‚ąă‚’ć‡șă—ćˆă„ă€çš†ăŒç›Žéąă™ă‚‹ć€šăăźéĄžäŒŒèȘČéĄŒă«ă€ă„ăŠè©±ă™ă“ăšăŒă§ăă€ăă—ăŠæ”ŻæŽă‚’ćŸ—ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ç§ăŸăĄăŻă•ăŸă–ăŸăȘç†ç”±ă‹ă‚‰ćŒă˜ć•éĄŒă«ć–ă‚Šç”„ăżă€ăă“ă§ăŠäș’ă„ă«ćŠ©ă‘ćˆă†ă“ăšăŒă§ăă‚‹ă€ăă†ă„ă†ç‚čăŒæ°—ă«ć…„ăŁăŠă„ăŸă™ă€‚ +--- + +
+

ă‚±ăƒŒă‚čă‚čă‚żăƒ‡ă‚ŁïŒš
ă‚čă‚żăƒŒăƒˆă‚ąăƒƒăƒ—ăŻă©ăźă‚ˆă†ă«ă—ăŠKubernetesă§ă‚€ăƒłăƒ•ăƒ©ă‚łă‚čトを50ïŒ…ă‚‚ć‰Šæž›ă—ăŸăźă‹

+ +
+ +
+ äŒæ„­ć  Nav     æ‰€ćœšćœ°  ăƒŠă‚żć·žă‚œăƒ«ăƒˆăƒŹă‚€ă‚Żă‚·ăƒ†ă‚Łă€ă‚«ăƒȘăƒ•ă‚©ăƒ«ăƒ‹ă‚ąć·žă‚”ăƒłăƒžăƒ†ă‚Ș     æ„­ç•Œ  äș‹æ„­è€…ć‘ă‘é‡‘èžă‚”ăƒŒăƒ“ă‚č +
+ +
+
+
+
+

+

èȘČ題

+2012ćčŽă«èš­ç«‹ă•ă‚ŒăŸ NavăŻă€ć°èŠæšĄäș‹æ„­è€…ăŸăĄă«ă€æ°‘é–“äżĄç”šèȘżæŸ»äŒæ„­äž»èŠ3瀟 —Equifax、Experian、DunBradstreet— ă«ăŠă‘ă‚‹ăƒ“ă‚žăƒă‚č信甹ă‚čă‚łă‚ąăšă€ćœŒă‚‰ăźăƒ‹ăƒŒă‚șă«æœ€é©ăȘèł‡é‡‘èȘżé”ă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’æäŸ›ă—ăŠă„ăŸă™ă€‚ă“ăźă‚čă‚żăƒŒăƒˆă‚ąăƒƒăƒ—ăŻ5ćčŽă§æ€„é€Ÿă«æˆé•·ă—ăŸă“ăšă§ă€ă€Œă‚Żăƒ©ă‚Šăƒ‰ç’°ćąƒăŒéžćžžă«ć€§ăăăȘăŁăŠă„ăŁăŸăźă§ă™ăŒă€ă“ă‚Œă‚‰ăźç’°ćąƒăźäœżç”šçŽ‡ăŻæ„”ç«Żă«äœŽăă€1ïŒ…ă‚’äž‹ć›žăŁăŠă„ăŸă—ăŸă€ăšă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒăźTravis JeppsonăŻèż°ăčăŠă„ăŸă™ă€‚ă€Œă‚Żăƒ©ă‚Šăƒ‰ç’°ćąƒăźäœżç”šçŽ‡ăšćźŸéš›ç§ăŸăĄă«ćż…èŠăȘもぼべを連拕させたかったぼで、搌じăƒȘă‚œăƒŒă‚čăƒ—ăƒŒăƒ«ă‚’ć…±æœ‰ă—ăȘăŒă‚‰è€‡æ•°ăźăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ăă‚Œăžă‚Œă‚’ćˆ†é›ąă—ăŠćźŸèĄŒă§ăă‚‹ă‚łăƒłăƒ†ăƒŠćŒ–ă‚„ă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚’æ€œèšŽă—ăŸă—ăŸă€‚ă€ +

+

ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒł

+æ•°ć€šăăźă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒł ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’è©•äŸĄă—ăŸç”æžœă€NavăƒăƒŒăƒ ăŻ AWSäžŠă§çšŒćƒă™ă‚‹ Kubernetesă‚’æŽĄç”šă™ă‚‹ă“ăšă‚’æ±șă‚ăŸă—ăŸă€‚Kubernetesă‚’ć–ă‚Šć·»ăă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăźćŒ·ăżăŻäșșă‚’ćŒ•ăă€ă‘ă‚‹ç‚čă«ă‚ă‚Šă€ăă‚ŒăŒGoogleă‹ă‚‰ç”ŸăŸă‚ŒăŸă‚‚ăźă§ă‚ă‚‹ă“ăšă‚‚ăăźäž€ă€ă§ă™ă€‚ćŠ ăˆăŠă€ă€Œä»–ăźă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăŻă€ă‹ăȘă‚Šæ‰‹é–“ăŒă‹ă‹ă‚Šă€æœŹćœ“ă«è€‡é›‘ă§ć€§ăăȘă‚‚ăźă§ă—ăŸă€‚ăă—ăŠă™ăă«çźĄç†ă§ăă‚‹ă‹ăšă„ă†ç‚čにおいおも掳しいもたにăȘりがちでした」べJeppsonăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesăŻăăźćœ“æ™‚ăźç§ăŸăĄăźăƒ‹ăƒŒă‚șă«ćˆăŁăŸă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă«èžăżć‡șă›ă‚‹ă€ăšăŠă‚‚ă‚·ăƒłăƒ—ăƒ«ăȘやりæ–čă‚’æäŸ›ă—ăŠăă‚ŒăŸă—ăŸă€‚ă•ă‚‰ă«ăăźæ‹ĄćŒ”æ€§ăŻă€ç§ăŸăĄăŒKubernetesăšć…±ă«æˆé•·ă—ă€ăăźćŸŒăźèżœćŠ æ©Ÿèƒœă‚’ç”„ăżć…„ă‚Œă‚‹ă“ăšă‚’ćŻèƒœă«ă—ăŠăă‚ŒăŸă—ăŸă€‚ă€ + +

ă‚€ăƒłăƒ‘ă‚Żăƒˆ

+4äșșç·šæˆăźăƒăƒŒăƒ ăŻă€6ă‹æœˆă§Kubernetesă‚’çšŒćƒă•ă›ă€ăăźćŸŒăź6ăƒ¶æœˆă§Navた25ă‚ăŁăŸăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čすăčăŠăźăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłă‚’ćźŒäș†ă•ă›ăŸă—ăŸă€‚ăăźç”æžœăŻç›źèŠšă—ă„ă‚‚ăźă§ă—ăŸă€‚ć°Žć…„ぼきっかけべăȘったăƒȘă‚œăƒŒă‚čäœżç”šçŽ‡ă«ă€ă„ăŠăŻă€1ïŒ…ă‹ă‚‰40ïŒ…ăŸă§ćą—ćŠ ă—ăŸă—ăŸă€‚ă‹ă€ăŠæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čを立づ䞊げるたに2äșșぼ開ç™șè€…ăŒ2é€±é–“ă‹ă‘ăŠă„ăŸă—ăŸăŒă€ă„ăŸă‚„é–‹ç™șè€…ăŻăŸăŁăŸäž€äșșで10ćˆ†ă‚‚ă‹ă‹ă‚ŠăŸă›ă‚“ă€‚ăƒ‡ăƒ—ăƒ­ă‚€æ•°ăŻ5ć€ćą—ăˆăŸă—ăŸă€‚ăă—ăŠćŒç€ŸăŻă‚€ăƒłăƒ•ăƒ©ă‚łă‚čトを50ïŒ…ć‰Šæž›ă—ăŠă„ăŸă™ă€‚ + +
+
+
+ +
+
+ +

+「KubernetesăŻăăźćœ“æ™‚ăźç§ăŸăĄăźăƒ‹ăƒŒă‚șă«ćˆăŁăŸă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă«èžăżć‡șă›ă‚‹ă€ăšăŠă‚‚ă‚·ăƒłăƒ—ăƒ«ăȘやりæ–čă‚’æäŸ›ă—ăŠăă‚ŒăŸă—ăŸă€‚ă•ă‚‰ă«ăăźæ‹ĄćŒ”æ€§ăŻă€ç§ăŸăĄăŒKubernetesăšć…±ă«æˆé•·ă—ă€ăăźćŸŒăźèżœćŠ æ©Ÿèƒœă‚’ç”„ăżć…„ă‚Œă‚‹ă“ăšă‚’ćŻèƒœă«ă—ăŠăă‚ŒăŸă—ăŸă€‚ă€ +

- Travis Jeppson、Nav スンゾニケăƒȘング ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒ
+
+
+
+

2012ćčŽă«èš­ç«‹ă•ă‚ŒăŸ NavăŻă€ć°èŠæšĄäș‹æ„­è€…ăŸăĄă«ă€æ°‘é–“äżĄç”šèȘżæŸ»äŒæ„­äž»èŠ3瀟 —Equifax、Experian、DunBradstreet— ă«ăŠă‘ă‚‹ăƒ“ă‚žăƒă‚č信甹ă‚čă‚łă‚ąăšă€ćœŒă‚‰ăźăƒ‹ăƒŒă‚șă«æœ€é©ăȘèł‡é‡‘èȘżé”ă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’æäŸ›ă—ăŠă„ăŸă™ă€‚ă€Œă‚čăƒąăƒŒăƒ«ăƒ“ă‚žăƒă‚čăźæˆćŠŸçŽ‡ă‚’äžŠă’ăŠă„ăă“ăšă€‚ă€ăăźăƒŸăƒƒă‚·ăƒ§ăƒłăŻă“ă“ă«ć‡çžźă•ă‚Œă‚‹ă€ăšă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒăźTravis JeppsonăŻèš€ă„ăŸă™ă€‚

+数ćčŽć‰ă€Navはè‡Șćˆ†ăŸăĄăźæˆćŠŸăžăźé“ç­‹ă«ă€éšœćźłăŒă‚ă‚‹ă“ăšă‚’èȘè­˜ă—ăŸă—ăŸă€‚ăƒ“ă‚žăƒă‚čăŒæ€„é€Ÿă«æˆé•·ă—ă€ă€Œă‚Żăƒ©ă‚Šăƒ‰ç’°ćąƒăŒéžćžžă«ć€§ăăăȘăŁăŠă„ăŁăŸăźă§ă™ăŒă€ă“ă‚Œă‚‰ăźç’°ćąƒăźäœżç”šçŽ‡ăŻæ„”ç«Żă«äœŽăă€1ïŒ…ă‚’äž‹ć›žăŁăŠă„ăŸă—ăŸă€ăšă€JeppsonăŻèš€ă„ăŸă™ă€‚ă€Œć•éĄŒăźć€§éƒšćˆ†ăŻă‚čă‚±ăƒŒăƒ«ă«é–ąă™ă‚‹ă‚‚ăźă§ă—ăŸă€‚ç§ăŸăĄăŻăă“ă«ăŸă ăŠé‡‘ă‚’æŠ•ć…„ă—ă‚ˆă†ăšă—ăŠă„ăŸă—ăŸă€‚ă€Žă‚‚ăŁăšć€šăăźă‚”ăƒŒăƒăƒŒă‚’çšŒćƒă•ă›ă‚ˆă†ă€‚ćą—ăˆăŸèČ è·ă‚’ă•ă°ăăŸă‚ă«ă‚ˆă‚Šć€šăäœœæ„­ă—ă‚ˆă†ă€ăšă„ăŁăŸć…·ćˆă«ă€‚ç§ăŸăĄăŻă‚čă‚żăƒŒăƒˆă‚ąăƒƒăƒ—ăȘぼで、そんăȘă“ăšă‚’ă—ăŠă„ăŠăŻç”‚ç„‰ăźäž€é€”ă‚’ăŸă©ă‚Šă‹ă­ăŸă›ă‚“ă—ă€ăă‚“ăȘă“ăšă«ă«äœżăˆă‚‹ă»ă©ăŠé‡‘ăźäœ™èŁ•ăŻæˆ‘ă€…ă«ăŻăȘいぼです。」 +

+ ă“ă†ă„ăŁăŸă“ăšă«ćŠ ăˆăŠă™ăčăŠăźæ–°ă‚”ăƒŒăƒ“ă‚čは違う10äșșă‚’ç”Œç”±ă—ăŠăƒȘăƒȘăƒŒă‚čされăȘければăȘă‚‰ăšă€ă‚”ăƒŒăƒ“ă‚č立づ䞊げに2é€±é–“ăšă„ă†ć—ă‘ć…„ă‚ŒăŒăŸă„ă»ă©ăźæ™‚é–“ă‚’ă‹ă‘ăŠă„ăŸăźă§ă™ă€‚ăƒ‘ăƒƒăƒçźĄç†ăšă‚”ăƒŒăƒçźĄç†ăźă™ăčăŠăŒæ‰‹ć‹•ă§èĄŒă‚ă‚ŒăŠă„ăŸăźă§ă€çš†ăŒăă‚Œă‚‰ă‚’èŠ‹ćźˆă‚Šă€ă†ăŸăç¶­æŒă—ăŠă„ăćż…èŠăŒă‚ăŁăŸăźă§ă™ă€ăšJeppsonăŻä»˜ă‘ćŠ ăˆăŸă™ă€‚ă€Œéžćžžă«ă‚„ăŁă‹ă„ăȘă‚·ă‚čテムでした。」 + +
+
+
+
ă€Œă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻéžćžžă«æŽ»ç™șă§ă™ă€‚ă‚ąă‚€ăƒ‡ă‚ąă‚’ć‡șă—ćˆă„ă€çš†ăŒç›Žéąă™ă‚‹ć€šăăźéĄžäŒŒèȘČéĄŒă«ă€ă„ăŠè©±ă™ă“ăšăŒă§ăă€ăă—ăŠæ”ŻæŽă‚’ćŸ—ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ç§ăŸăĄăŻă•ăŸă–ăŸăȘç†ç”±ă‹ă‚‰ćŒă˜ć•éĄŒă«ć–ă‚Šç”„ăżă€ăă“ă§ăŠäș’ă„ă«ćŠ©ă‘ćˆă†ă“ăšăŒă§ăă‚‹ă€ăă†ă„ă†ç‚čăŒæ°—ă«ć…„ăŁăŠă„ăŸă™ă€‚ă€

- Travis Jeppson、Nav スンゾニケăƒȘăƒłă‚°ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒ
+ + +
+
+
JeppsonăŻć‰è·ă§ă‚łăƒłăƒ†ăƒŠă‚’ć–ă‚Šæ‰±ăŁăŠă„ăŸăŸă‚ă€Navăźç”Œć–¶é™Łă«ă“ă‚Œă‚‰ăźć•éĄŒăźè§Łæ±șç­–ăšă—ăŠă“ăźæŠ€èĄ“ă‚’ćŁČă‚ŠèŸŒăżăŸă—ăŸă€‚ăă—ăŠ2017ćčŽćˆă‚ćœŒăźææĄˆă«ă‚ŽăƒŒă‚”ă‚€ăƒłăŒă§ăŸă—ăŸă€‚ă€Œă‚Żăƒ©ă‚Šăƒ‰ç’°ćąƒăźäœżç”šçŽ‡ăšćźŸéš›ç§ăŸăĄă«ćż…èŠăȘă‚‚ăźăšă‚’é€Łć‹•ă•ă›ăŸă‹ăŁăŸăźă§ă€éĄžäŒŒă—ăŸăƒȘă‚œăƒŒă‚čăƒ—ăƒŒăƒ«ă‚’ć…±æœ‰ă—ăȘăŒă‚‰è€‡æ•°ăźăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ăă‚Œăžă‚Œă‚’ćˆ†é›ąă—ăŠćźŸèĄŒă§ăă‚‹ă‚łăƒłăƒ†ăƒŠćŒ–ă‚„ă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚’æ€œèšŽă—ăŸă—ăŸă€ăšă€ćœŒăŻèš€ă„ăŸă™ă€‚

+ æ•°ć€šăăźă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’è©•äŸĄă—ăŸç”æžœă€NavăƒăƒŒăƒ ăŻ AWSでたKubernetes æŽĄç”šă‚’æ±șæ–­ă—ăŸă—ăŸă€‚Kubernetesă‚’ć–ă‚Šć·»ăă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăźćŒ·ăżăŻäșșă‚’ćŒ•ăă€ă‘ă‚‹ç‚čă«ă‚ă‚Šă€ăă‚ŒăŒGoogleă‹ă‚‰ç”ŸăŸă‚ŒăŸă‚‚ăźă§ă‚ă‚‹ă“ăšă‚‚ăăźäž€ă€ă§ă™ă€‚ćŠ ăˆăŠă€ă€Œä»–ăźă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăŻă€ă‹ăȘă‚Šæ‰‹é–“ăŒă‹ă‹ă‚Šă€æœŹćœ“ă«è€‡é›‘ă§ć€§ăăȘă‚‚ăźă§ă—ăŸă€‚ăă—ăŠă™ăă«çźĄç†ă§ăă‚‹ă‹ăšă„ă†ç‚čにおいおも掳しいもたにăȘりがちでした」べJeppsonăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesăŻăăźćœ“æ™‚ăźç§ăŸăĄăźăƒ‹ăƒŒă‚șă«ćˆăŁăŸă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă«èžăżć‡șă›ă‚‹ă€ăšăŠă‚‚ă‚·ăƒłăƒ—ăƒ«ăȘやりæ–čă‚’æäŸ›ă—ăŠăă‚ŒăŸă—ăŸă€‚äž€æ–čă§ăăźæ‹ĄćŒ”æ€§ăŻă€ç§ăŸăĄăŒKubernetesăšć…±ă«æˆé•·ă—ă€ăăźćŸŒăźèżœćŠ æ©Ÿèƒœă‚’ç”„ăżć…„ă‚Œă‚‹ă“ăšă‚’ćŻèƒœă«ă—ăŠăă‚ŒăŸă—ăŸă€‚ă€

+ Jeppsonた4äșșç·šæˆăźă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ă‚”ăƒŒăƒ“ă‚čăƒăƒŒăƒ ăŻă€Kubernetesă‚’ç«‹ăĄäžŠă’ă€çšŒćƒă•ă›ă‚‹ăźă«6ăƒ¶æœˆă‹ă‘ăŸă—ăŸïŒˆă‚Żăƒ©ă‚čă‚żăƒŒă‚’ć‹•ă‹ă™ăŸă‚ă« Kubespray ă‚’äœżă„ăŸă—ăŸïŒ‰ă€‚ăă—ăŠă€ăăźćŸŒ6ăƒ¶æœˆă‹ă‘Navた25ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čăšäž€ă€ăźăƒąăƒŽăƒȘă‚·ăƒƒă‚ŻăȘäž»èŠă‚”ăƒŒăƒ“ă‚čăźăƒ•ăƒ«ăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłă‚’ćźŒäș†ă•ă›ăŸă—ăŸă€‚ă€Œă™ăčăŠæ›žăæ›ăˆăŸă‚Šă€æ­ąă‚ă‚‹ă“ăšăŻă§ăăŸă›ă‚“ă§ă—ăŸă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€ŒçšŒćƒă—ă€ćˆ©ç”šćŻèƒœă§ă‚ă‚Šç¶šă‘ăȘければいけăȘă‹ăŁăŸă§ă™ă—ă€ăƒ€ă‚Šăƒłă‚żă‚€ăƒ ăŒă‚ăŁăŠă‚‚ă‚’ăă‚Œă‚’æœ€ć°ă«ă—ăȘければăȘă‚ŠăŸă›ă‚“ă§ă—ăŸă€‚ăăźăŸă‚ăƒ‘ă‚€ăƒ—ăƒ©ă‚€ăƒłäœœæˆă€ăƒĄăƒˆăƒȘクă‚čă‚„ăƒ­ă‚źăƒłă‚°ăšă„ăŁăŸă“ăšă«ă€ă„ăŠă‚ˆăă‚ă‹ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă•ă‚‰ă«Kubernetesè‡Șèș«ă«ă€ă„ăŠă‚‚çż’ç†Ÿă—ă€è”·ć‹•ă€ă‚ąăƒƒăƒ—ă‚°ăƒŹăƒŒăƒ‰ă€ă‚”ăƒŒăƒ“ă‚čæäŸ›ăźä»•æ–čă«ă€ă„ăŠă‚‚ă‚ă‹ă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ăă†ă—ăŠç§»èĄŒă‚’ć°‘ă—ăšă€é€Čă‚ăŠă„ăăŸă—ăŸă€‚ă€ +
+
+
+
+「KubernetesăŻă€ă“ă‚ŒăŸă§ç”Œéš“ă—ăŸă“ăšăźăȘă„æ–°ăŸăȘè‡Șç”±ăšăŸăă•ă‚“ăźäŸĄć€€ă‚’Navă«ă‚‚ăŸă‚‰ă—ăŠăă‚ŒăŸă—ăŸă€‚ă€

- Travis Jeppson、Nav スンゾニケăƒȘăƒłă‚°ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒ +
+
+ +
+ +
+ă“ăźéŽçš‹ă§é‡èŠă ăŁăŸăźăŻă€Navた50äșșăźă‚šăƒłă‚žăƒ‹ă‚ąă‚’æ•™è‚Čă™ă‚‹ă“ăšă€ăă—ăŠăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłă«ćœ“ăŸă‚Šæ–°ăŸăȘăƒŻăƒŒă‚Żăƒ•ăƒ­ăƒŒă‚„ăƒ­ăƒŒăƒ‰ăƒžăƒƒăƒ—ă«ă€ă„ăŠé€æ˜Žæ€§ă‚’çąș保するこべでした。 +そこでJeppsonはスンゾニケăƒȘングă‚čă‚żăƒƒăƒ•ć…šć“Ąă«ćŻŸă—ćźšæœŸçš„ăȘăƒ—ăƒŹă‚Œăƒłăƒ†ăƒŒă‚·ăƒ§ăƒłă‚„ă€äž€é€±é–“ă«ă‚ăŸă‚‹1æ—„4æ™‚é–“ăźćźŸçż’ăźć Žă‚’èš­ă‘ăŸă—ăŸă€‚ăă—ăŠćœŒăŻă™ăčăŠăźæƒ…ć ±ă‚’çœźă„ăŠăŠăăŸă‚ă« GitLabにăƒȘポゾトăƒȘă‚’äœœæˆă—ăŸă—ăŸă€‚ 「フロントスンドべバックスンドぼ開ç™șè€…ăŸăĄć…šć“Ąă«ă€kubectlを甹い、独抛でnamespaceă‚’äœœæˆă—ă€ć–ă‚Šæ‰±ă†æ–čæł•ă‚’èŠ‹ă›ăŠă„ăăŸă—ăŸă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€Œă„ăŸă‚„ă€ćœŒă‚‰ăŻă‚„ăŁăŠăăŠă€Žă“ă‚ŒăŻæș–ć‚™OKă ă€ăšă„ă†ă ă‘ă§æžˆă‚€ă“ăšăŒć€šăăȘă‚ŠăŸă—ăŸă€‚GitLabぼ氏さăȘボタンをクăƒȘăƒƒă‚Żă™ă‚Œă°æœŹç•Șç’°ćąƒă«ăƒȘăƒȘăƒŒă‚čă§ăă‚‹ă‚ˆă†ă«ăȘăŁăŠă„ă‚‹ăźă§ćœŒă‚‰ăŻă™ăă«æŹĄăźèĄŒć‹•ă«ç§»ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă€

+ ăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăŒ2018ćčŽćˆă‚ă«ćźŒäș†ă—ăŸă‚ăšăźç”æžœăŻç›źèŠšă—ă„ă‚‚ăźă§ă—ăŸă€‚ć°Žć…„ぼきっかけべăȘったăƒȘă‚œăƒŒă‚čäœżç”šçŽ‡ă«ă€ă„ăŠăŻă€1ïŒ…ă‹ă‚‰40ïŒ…ăŸă§ćą—ćŠ ă—ăŸă—ăŸă€‚ă‹ă€ăŠæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čを立づ䞊げるたに2äșșぼ開ç™șè€…ăŒ2é€±é–“ă‹ă‘ăŠă„ăŸă—ăŸăŒă€ă„ăŸă‚„é–‹ç™șè€…ăŻăŸăŁăŸäž€äșșで10ćˆ†ă‚‚ă‹ă‹ă‚ŠăŸă›ă‚“ă€‚ăƒ‡ăƒ—ăƒ­ă‚€æ•°ăŻ1æ—„ă‚ăŸă‚Š10だったもぼから50ずăȘり5ć€ćą—ăˆăŸă—ăŸă€‚ăă—ăŠćŒç€ŸăŻă‚€ăƒłăƒ•ăƒ©ă‚łă‚čトを50ïŒ…ć‰Šæž›ă—ăŠă„ăŸă™ă€‚ă€ŒæŹĄăŻăƒ‡ăƒŒă‚żăƒ™ăƒŒă‚čćŽă«ć–ă‚Šç”„ăżăŸă„ă§ă™ă€‚ăă‚ŒăŒă§ăă‚Œă°ă‹ăȘりぼコă‚čăƒˆć‰Šæž›ă‚’ç¶™ç¶šă§ăă‚‹ă§ă—ă‚‡ă†ă€ăšJeppsonăŻèš€ă„ăŸă™ă€‚

+ ăŸăŸă€KubernetesはNavăźă‚łăƒłăƒ—ăƒ©ă‚€ă‚ąăƒłă‚čăźăƒ‹ăƒŒă‚șにも抛をèČžă—ăŸă—ăŸă€‚ä»„ć‰ăŻă€ă€Œ1ă€ăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’1ă€ăźă‚”ăƒŒăƒăƒŒă«ăƒžăƒƒăƒ”ăƒłă‚°ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă—ăŸă€‚ă“ă‚ŒăŻäž»ă«ăƒ‡ăƒŒă‚żć‘šèŸșă§ă‚łăƒłăƒ—ăƒ©ă‚€ă‚ąăƒłă‚čぼ異ăȘă‚‹ăƒŹă‚źăƒ„ăƒŹăƒŒă‚·ăƒ§ăƒłăŒă‚ăŁăŸăŸă‚ă§ă™ă€ăšJeppsonăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesたAPIă‚’ç”šă„ă‚Œă°ă€ăƒăƒƒăƒˆăƒŻăƒŒă‚ŻăƒăƒȘă‚·ăƒŒă‚’èżœćŠ ă—ă€ćż…èŠă«ćżœă˜ăŠăă‚Œă‚‰ăźăƒ‡ăƒŒă‚żă‚’ćˆ†é›ąă—ćˆ¶é™ă‚’ă‹ă‘ă‚‹ă“ăšăŒă§ăă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă™ă€‚ă€ćŒç€ŸăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒă‚’èŠćˆ¶ăźăȘă„ă‚ŸăƒŒăƒłăšă€ç‹Źè‡ȘăƒŽăƒŒăƒ‰ă‚»ăƒƒăƒˆă‚’æŒăŁăŸăƒ‡ăƒŒă‚żäżè­·ă‚’èĄŒă†ăčăèŠćˆ¶ă‚ŸăƒŒăƒłă«ćˆ†é›ąă—ăŠă„ăŸă™ă€‚ăŸăŸă€Twistlockăƒ„ăƒŒăƒ«ă‚’äœżç”šă™ă‚‹ă“ăšă§ă‚»ă‚­ăƒ„ăƒȘティをçąșäżă—ăŠă„ăŸă™ă€‚ă€Œć€œă€ă‚ˆăçœ ă‚Œă‚‹ă“ăšă‚‚ă­ă€ăšćœŒăŻä»˜ă‘ćŠ ăˆăŸă™ă€‚ +
+ +
+
ă€Œä»Šç§ăŸăĄăŒæ‰±ăŁăŠă„ă‚‹ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żé‡ăź4〜10ć€ăŒæ”ă‚ŒăŸăšă—ăŠă‚‚ă€ă€Žă‚ă‚ă€ć€§äžˆć€«ă ă‚ˆă€KubernetesăŒă‚„ăŁăŠăă‚Œă‚‹ă‹ă‚‰ă€ăšè©±ă—ăŠă„ăŸă™ă€‚ă€

- Travis Jeppson、Nav スンゾニケăƒȘング ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒ
+
+ +
+ KubernetesăŒć°Žć…„ă•ă‚ŒăŸäž­ă€NavăƒăƒŒăƒ ăŻ Prometheusă‚’æŽĄç”šă—ăŠă‚·ă‚čテムぼメトăƒȘクă‚čやロゼングぼæ”čè‰Żă‚‚ć§‹ă‚ăŸă—ăŸă€‚ă€‚ă€ŒPrometheusは開ç™șè€…ă«ăšăŁăŠă€ăšăŠă‚‚æŽĄç”šă—ă‚„ă™ă„ăƒĄăƒˆăƒȘクă‚čăźæš™æș–ă‚’äœœăŁăŠăă‚ŒăŸă—ăŸă€ăšJeppsonăŻèš€ă„ăŸă™ă€‚ă€ŒćœŒă‚‰ă«ăŻă€äœ•ă‚’ă—ăŸă„ă‹ă‚’ç€șă—ă€ă—ăŸă„ă“ăšă‚’ćźŸè·”ă—ă€ăă—ăŠćœŒă‚‰ăźă‚łăƒŒăƒ‰ăƒ™ăƒŒă‚čをクăƒȘăƒŒăƒłăȘçŠ¶æ…‹ă«äżă€è‡Șç”±ăŒă‚ă‚ŠăŸă™ă€‚ăă—ăŠç§ăŸăĄă«ăšăŁăŠăă‚ŒăŻăŸăĄăŒă„ăȘく濅須äș‹é …ă§ă—ăŸă€‚ă€

+ ă“ă‚Œă‹ă‚‰ć…ˆă‚’èŠ‹æźăˆă€æŹĄă«NavăŒæ„æŹČçš„ă«èŠ–é‡Žă«ć…„ă‚ŒăŠă„ă‚‹ăźăŻă€ăƒˆăƒŹăƒŒă‚·ăƒłă‚°(Tracing)、ă‚čăƒˆăƒŹăƒŒă‚žă€ăă—ăŠă‚”ăƒŒăƒ“ă‚čăƒĄăƒƒă‚·ăƒ„ă§ă™ă€‚ăă—ăŠKubeConă§ć€šăăźæ™‚é–“ă‚’ă„ă‚ă‚“ăȘäŒæ„­ăšăźćŻŸè©±ă«èČ»ă‚„ă—ăŸăăźćŸŒă§ă€çŸćœšćœŒă‚‰ăŻEnvoy、 OpenTracing、そしど Jaegeră‚’æ€œèšŒă—ăŠă„ăŸă™ă€‚ă€Œă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻéžćžžă«æŽ»ç™șă§ă™ă€‚ă‚ąă‚€ăƒ‡ă‚ąă‚’ć‡șă—ćˆă„ă€çš†ăŒç›Žéąă™ă‚‹ć€šăăźéĄžäŒŒèȘČéĄŒă«ă€ă„ăŠè©±ă™ă“ăšăŒă§ăă€ăă—ăŠæ”ŻæŽă‚’ćŸ—ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ç§ăŸăĄăŻă•ăŸă–ăŸăȘç†ç”±ă‹ă‚‰ćŒă˜ć•éĄŒă«ć–ă‚Šç”„ăżă€ăă“ă§ăŠäș’ă„ă«ćŠ©ă‘ćˆă†ă“ăšăŒă§ăă‚‹ă€ăă†ă„ă†ç‚čăŒæ°—ă«ć…„ăŁăŠă„ăŸă™ă€ăšJeppsonăŻèš€ă„ăŸă™ă€‚ă€Œă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăȘă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’ăƒ•ăƒ«ă«æŽĄç”šă§ăă‚‹ă‚ˆă†ă«ăȘるには、ă‚čă‚±ăƒŒăƒ©ăƒ“ăƒȘティ靱でやるăčăă“ăšăŒăŸă ăŸăă•ă‚“ă‚ă‚ŠăŸă™ă€‚ă€

+ もちろん、すăčおはKubernetesă‹ă‚‰ć§‹ăŸă‚ŠăŸă™ă€‚JeppsonăźăƒăƒŒăƒ ăŻă€ă“ăźæŠ€èĄ“ă§Navをă‚čă‚±ăƒŒăƒ«ćŻèƒœă«ă™ă‚‹ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚’æ§‹çŻ‰ă—ăŸă—ăŸă€‚ăă—ăŠă€Œă“ă‚ŒăŸă§ç”Œéš“ă—ăŸă“ăšăźăȘă„æ–°ăŸăȘè‡Șç”±ă€ăŸăă•ă‚“ăźäŸĄć€€ă‚’Navă«ă‚‚ăŸă‚‰ă—ăŠăă‚ŒăŸăźă§ă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚æ–°èŁœć“ă‚’æ€œèšŽă—ă‚ˆă†ă«ă‚‚ă€éš”é›ąă•ă‚ŒăŸç’°ćąƒă‚’ç”šæ„ă™ă‚‹ăźă«6ă‹æœˆćŸ…ăŸăȘければăȘă‚‰ăšă€ăăźćŸŒă‚‚ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚ŻăŒæ€„äžŠæ˜‡ă™ă‚‹ăźă«ćŻŸćżœă™ă‚‹ă‚„ă‚Šă‹ăŸă‚‚è€ƒăˆć‡șさăȘければăȘらăȘいべいうäș‹ćźŸăŒă‚り、èș«ć‹•ăăŒć–ă‚ŒăȘくăȘăŁăŠă—ăŸăŁăŠă„ăŸă—ăŸă€‚ă€Œă—ă‹ă—ă€ă‚‚ă†ăă†ă„ăŁăŸè©±ă‚‚ăȘくăȘă‚ŠăŸă—ăŸă€‚ă€ăšJeppsonăŻèš€ă„ăŸă™ă€‚ă€Œä»Šç§ăŸăĄăŒæ‰±ăŁăŠă„ă‚‹ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żé‡ăź4〜10ć€ăŒæ”ă‚ŒăŸăšă—ăŠă‚‚ă€ă€Žă‚ă‚ă€ć€§äžˆć€«ă ă‚ˆă€KubernetesăŒă‚„ăŁăŠăă‚Œă‚‹ă‹ă‚‰ă€ăšè©±ă—ăŠă„ăŸă™ă€‚ă€ + +
+
diff --git a/content/ja/case-studies/nav/nav_featured_logo.png b/content/ja/case-studies/nav/nav_featured_logo.png new file mode 100644 index 0000000000..22d96017c4 Binary files /dev/null and b/content/ja/case-studies/nav/nav_featured_logo.png differ diff --git a/content/ja/case-studies/nordstrom/index.html b/content/ja/case-studies/nordstrom/index.html index 3a9f6473bc..e867f49d7c 100644 --- a/content/ja/case-studies/nordstrom/index.html +++ b/content/ja/case-studies/nordstrom/index.html @@ -40,7 +40,7 @@ css: /css/style_case_studies.css
- ç§ăŸăĄăŻćžžă«ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’é€šă˜ăŠæœ€é©ćŒ–ă—ăŠă‚ˆă‚Šć€§ăăȘäŸĄć€€ă‚’æäŸ›ă™ă‚‹æ–čæł•ă‚’æŽąă—ăŠă„ăŸă™ă€‚Kubernetesを甹いど私たちは開ç™șćŠč率べ運甹ćŠč率べいう2぀たćŠč率をç€șă—ăŸă™ă€‚ă“ă‚ŒăŻćŒæ–čă«ăšăŁăŠć„œéƒœćˆă§ă™ă€‚ + ç§ăŸăĄăŻćžžă«ă€æŠ€èĄ“ăźæœ€é©ćŒ–ă‚’é€šă˜ăŠă‚ˆă‚Šć€§ăăȘäŸĄć€€ă‚’æäŸ›ă™ă‚‹æ–čæł•ă‚’æŽąă—ăŠă„ăŸă™ă€‚Kubernetesを甹いど私たちは開ç™șćŠč率べ運甹ćŠč率べいう2぀たćŠč率をç€șă—ăŸă™ă€‚ă“ă‚ŒăŻćŒæ–čă«ăšăŁăŠć„œéƒœćˆă§ă™ă€‚

-Nordstromç€Ÿă‚·ăƒ‹ă‚ąă‚šăƒłă‚žăƒ‹ă‚ą Dhawal Patel
diff --git a/content/ja/case-studies/sos/index.html b/content/ja/case-studies/sos/index.html index bce9834275..3fe901610b 100644 --- a/content/ja/case-studies/sos/index.html +++ b/content/ja/case-studies/sos/index.html @@ -26,22 +26,22 @@ logo: sos_featured_logo.png

èȘČ題

SOS Internationalは60ćčŽă«ă‚ăŸă‚Šă€ćŒ—æŹ§è«žć›œăźéĄ§ćźąă«äżĄé Œæ€§ăźé«˜ă„ç·Šæ€„ćŒ»ç™‚ăŠă‚ˆăłæ—…èĄŒæ”ŻæŽă‚’æäŸ›ă—ăŠăăŸă—ăŸă€‚èż‘ćčŽă€ćŒç€Ÿăźăƒ“ă‚žăƒă‚čæˆŠç•„ă§ăŻă€ăƒ‡ă‚žă‚żăƒ«ćˆ†é‡Žă§ăźé–‹ç™șă‚’ă•ă‚‰ă«ćŒ·ćŒ–ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă—ăŸăŒă€ITă‚·ă‚čăƒ†ăƒ ă«é–ąă—ăŠăŻ -3ă€ăźćŸ“æ„ăźăƒąăƒŽăƒȘă‚č(Java, .NET, およびIBMたAS/400)ăšă‚Šă‚©ăƒŒă‚żăƒŒăƒ•ă‚©ăƒŒăƒ«ă‚ąăƒ—ăƒ­ăƒŒăƒă«ăŠă„ăŠă€ŒSOSă«ăŻéžćžžă«æ–­ç‰‡ćŒ–ă•ă‚ŒăŸéșç”ŁăŒă‚ă‚ŠăŸă™ă€‚ă€ăšă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€…ăźMartin Ahrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œæ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăšæ–°ă—ă„ćƒăæ–čた䞥æ–čă‚’ć°Žć…„ă™ă‚‹ă“ăšă‚’äœ™ć„€ăȘăă•ă‚ŒăŠă„ă‚‹ăźă§ă€ćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă‚’çŸ­çžźă—ăŠćŠčçŽ‡ă‚’é«˜ă‚ă‚‹ă“ăšăŒă§ăăŸă—ăŸă€‚ăă‚ŒăŻăŻă‚‹ă‹ă«æ©Ÿæ•ăȘă‚ąăƒ—ăƒ­ăƒŒăƒă§ă‚ă‚Šă€ç§ăŸăĄă«ăŻăă‚Œă‚’ăƒ“ă‚žăƒă‚čă«æäŸ›ă™ă‚‹ăźă«ćœčç«‹ă€ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒćż…èŠă§ă—ăŸă€‚ă€ +3ă€ăźćŸ“æ„ăźăƒąăƒŽăƒȘă‚č(Java, .NET, およびIBMたAS/400)ăšă‚Šă‚©ăƒŒă‚żăƒŒăƒ•ă‚©ăƒŒăƒ«ă‚ąăƒ—ăƒ­ăƒŒăƒă«ăŠă„ăŠă€ŒSOSă«ăŻéžćžžă«æ–­ç‰‡ćŒ–ă•ă‚ŒăŸéșç”ŁăŒă‚ă‚ŠăŸă™ă€‚ă€ăšă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€…ăźMartin Ahrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œæ–°ă—ă„æŠ€èĄ“ăšæ–°ă—ă„ćƒăæ–čた䞥æ–čă‚’ć°Žć…„ă™ă‚‹ă“ăšă‚’äœ™ć„€ăȘăă•ă‚ŒăŠă„ă‚‹ăźă§ă€ćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă‚’çŸ­çžźă—ăŠćŠčçŽ‡ă‚’é«˜ă‚ă‚‹ă“ăšăŒă§ăăŸă—ăŸă€‚ăă‚ŒăŻăŻă‚‹ă‹ă«æ©Ÿæ•ăȘă‚ąăƒ—ăƒ­ăƒŒăƒă§ă‚ă‚Šă€ç§ăŸăĄă«ăŻăă‚Œă‚’ăƒ“ă‚žăƒă‚čă«æäŸ›ă™ă‚‹ăźă«ćœčç«‹ă€ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒćż…èŠă§ă—ăŸă€‚ă€

ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒł

- æš™æș–ă‚·ă‚čăƒ†ăƒ ăźæšĄçŽąă«ć€±æ•—ă—ăŸćŸŒă€ćŒç€ŸăŻăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚ąăƒ—ăƒ­ăƒŒăƒă‚’æŽĄç”šă—ă€Kubernetesăšă‚łăƒłăƒ†ăƒŠăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’ćŒ…ć«ă™ă‚‹ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’æŽąă™ă“ăšă«ă—ăŸă—ăŸă€‚RedHat OpenShiftはSOSăźæ–­ç‰‡ćŒ–ă•ă‚ŒăŸă‚·ă‚čăƒ†ăƒ ă«æœ€é©ă§ă‚ă‚‹ă“ăšăŒèšŒæ˜Žă•ă‚ŒăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻă‚łăƒŒăƒ‰èš€èȘžăšăăźä»–た䞥æ–čă‚’äœżç”šă™ă‚‹ć€šăăźç•°ăȘă‚‹æŠ€èĄ“ă‚’æŒăŁăŠă„ăŸă™ăŒă€ăă‚Œă‚‰ăŻă™ăčăŠæ–°ă—ă„ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠăźăƒȘă‚œăƒŒă‚čă‚’äœżç”šă§ăăŸă™ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ćŒç€Ÿăź3ă€ăźăƒąăƒŽăƒȘă‚čăźă†ăĄă€ă€Œă“ăźæœ€ć…ˆç«Żăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’2぀(.NETずJava)ă«æäŸ›ă§ăăŸă™ă€‚ă€ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻ2018ćčŽæ˜„ă«ć…Źé–‹ă•ă‚ŒăŸă—ăŸă€‚çŸćœšă€ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒă«ćŸșă„ă6぀たæœȘ開ç™șプロゾェクトがé€ČèĄŒäž­ă§ă‚ă‚Šă€ă•ă‚‰ă«ă€ćŒç€ŸăźJavaケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăŻă™ăčど「ăƒȘフト&ă‚·ăƒ•ăƒˆă€ç§»èĄŒă‚’èĄŒăŁăŠă„ăŸă™ă€‚ + æš™æș–ă‚·ă‚čăƒ†ăƒ ăźæšĄçŽąă«ć€±æ•—ă—ăŸćŸŒă€ćŒç€ŸăŻăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚ąăƒ—ăƒ­ăƒŒăƒă‚’æŽĄç”šă—ă€Kubernetesăšă‚łăƒłăƒ†ăƒŠæŠ€èĄ“ă‚’ćŒ…ć«ă™ă‚‹ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’æŽąă™ă“ăšă«ă—ăŸă—ăŸă€‚RedHat OpenShiftはSOSăźæ–­ç‰‡ćŒ–ă•ă‚ŒăŸă‚·ă‚čăƒ†ăƒ ă«æœ€é©ă§ă‚ă‚‹ă“ăšăŒèšŒæ˜Žă•ă‚ŒăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻă‚łăƒŒăƒ‰èš€èȘžăšăăźä»–た䞥æ–čă‚’äœżç”šă™ă‚‹ć€šăăźç•°ăȘă‚‹æŠ€èĄ“ă‚’æŒăŁăŠă„ăŸă™ăŒă€ăă‚Œă‚‰ăŻă™ăčăŠæ–°ă—ă„ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠăźăƒȘă‚œăƒŒă‚čă‚’äœżç”šă§ăăŸă™ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ćŒç€Ÿă«ă‚ă‚‹3ă€ăźăƒąăƒŽăƒȘă‚čぼ侭で、「2぀(.NETずJava)ă«ćŻŸă—ăŠă“ăźæœ€ć…ˆç«ŻăźæŠ€èĄ“ă‚’æäŸ›ă§ăăŸă™ă€‚ă€ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻ2018ćčŽæ˜„ă«ć…Źé–‹ă•ă‚ŒăŸă—ăŸă€‚çŸćœšă€ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒă«ćŸșă„ă6぀たæœȘ開ç™șプロゾェクトがé€ČèĄŒäž­ă§ă‚ă‚Šă€ă•ă‚‰ă«ă€ćŒç€ŸăźJavaケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăŻă™ăčど「ăƒȘフト&ă‚·ăƒ•ăƒˆă€ç§»èĄŒă‚’èĄŒăŁăŠă„ăŸă™ă€‚

ćœ±éŸż

- Kubernetesă«ă‚ˆăŁăŠă€Œćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă€ă‚ąă‚žăƒȘăƒ†ă‚Łă€ăŠă‚ˆăłć€‰æ›Žăšæ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă«é©ćżœă™ă‚‹èƒœćŠ›ăźć‘äžŠă‚’ćźŸçŸă—ăŸă—ăŸă€‚ă€ăšAhrentsenæ°ăŻèȘžă‚ŠăŸă™ă€‚ă€Œă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăźăƒȘăƒȘăƒŒă‚čæș–ć‚™ăŒă§ăăŠă‹ă‚‰ăƒȘăƒȘăƒŒă‚čă§ăă‚‹ăŸă§ăźæ™‚é–“ăŒć€§ćč…にæ”čć–„ă•ă‚ŒăŸă—ăŸă€‚ă€SOS Internationalăźè€ƒăˆæ–čă‚‚ćŠ‡çš„ă«ć€‰ă‚ă‚ŠăŸă—ăŸă€‚ă€Œè‡Ș拕挖、CI/CDăƒ‘ă‚€ăƒ—ăƒ©ă‚€ăƒłăźäœœæˆă‚’ćźčæ˜“ă«ă™ă‚‹Kubernetesずă‚čクăƒȘプトまぼ簡捘ăȘă‚ąă‚Żă‚»ă‚čがあるぼで、こぼ漌慹è‡Ș拕挖ぼæ–čæł•ă«è‡łă‚‹æ‰€ă§ć€šăăźć†…éƒšçš„ăȘé–ąćżƒăŒç”ŸăŸă‚ŒăŠă„ăŸă™ă€‚æ—…ă‚’ć§‹ă‚ă‚‹ăŸă‚ă«éžćžžă«è‰Żă„æ°—ć€™ă‚’äœœă‚Šć‡șă—ăŠă„ăŸă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă•ă‚‰ă«ă€ă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łăźäž€ć“Ąă§ă‚ă‚‹ă“ăšăŻă€ćŒç€ŸăŒäșșæă‚’ćŒ•ăä»˜ă‘ă‚‹ăźă«ćœčç«‹ăĄăŸă—ăŸă€‚ă€ŒćœŒă‚‰ăŻă‚ŻăƒŒăƒ«ă§æ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’äœżă„ăŸă„ăšæ€ăŁăŠă„ăŸă™ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œæ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§ITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€ + Kubernetesă«ă‚ˆăŁăŠă€Œćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă€ă‚ąă‚žăƒȘăƒ†ă‚Łă€ăŠă‚ˆăłć€‰æ›Žăšæ–°ă—ă„æŠ€èĄ“ă«é©ćżœă™ă‚‹èƒœćŠ›ăźć‘äžŠă‚’ćźŸçŸă—ăŸă—ăŸă€‚ă€ăšAhrentsenæ°ăŻèȘžă‚ŠăŸă™ă€‚ă€Œă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăźăƒȘăƒȘăƒŒă‚čæș–ć‚™ăŒă§ăăŠă‹ă‚‰ăƒȘăƒȘăƒŒă‚čă§ăă‚‹ăŸă§ăźæ™‚é–“ăŒć€§ćč…にæ”čć–„ă•ă‚ŒăŸă—ăŸă€‚ă€SOS Internationalăźè€ƒăˆæ–čă‚‚ćŠ‡çš„ă«ć€‰ă‚ă‚ŠăŸă—ăŸă€‚ă€Œè‡Ș拕挖、CI/CDăƒ‘ă‚€ăƒ—ăƒ©ă‚€ăƒłăźäœœæˆă‚’ćźčæ˜“ă«ă™ă‚‹Kubernetesずă‚čクăƒȘプトまぼ簡捘ăȘă‚ąă‚Żă‚»ă‚čがあるぼで、こぼ漌慹è‡Ș拕挖ぼæ–čæł•ă«è‡łă‚‹æ‰€ă§ć€šăăźć†…éƒšçš„ăȘé–ąćżƒăŒç”ŸăŸă‚ŒăŠă„ăŸă™ă€‚æ—…ă‚’ć§‹ă‚ă‚‹ăŸă‚ă«éžćžžă«è‰Żă„æ°—ć€™ă‚’äœœă‚Šć‡șă—ăŠă„ăŸă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă•ă‚‰ă«ă€ă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łăźäž€ć“Ąă§ă‚ă‚‹ă“ăšăŻă€ćŒç€ŸăŒäșșæă‚’ćŒ•ăä»˜ă‘ă‚‹ăźă«ćœčç«‹ăĄăŸă—ăŸă€‚ă€ŒćœŒă‚‰ăŻă‚ŻăƒŒăƒ«ă§æ–°ă—ă„æŠ€èĄ“ă‚’äœżă„ăŸă„ăšæ€ăŁăŠă„ăŸă™ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€ŒITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæ–°ă—ă„æŠ€èĄ“ă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§æˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€
- ă€Œă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăšăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŒçŸćœšæŽšé€Čă—ăŠă„ă‚‹ć€‰ćŒ–ăźé€ŸćșŠăŻé©šăăčăă‚‚ăźă§ă‚ă‚Šă€ăă‚Œă‚’ăƒ•ă‚©ăƒ­ăƒŒă—ăŠæŽĄç”šă™ă‚‹ă“ăšăŻç§ăŸăĄă«ăšăŁăŠéžćžžă«é‡èŠă§ă™ă€‚Kubernetesăšă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăŒæäŸ›ă™ă‚‹é©šăăčăæŠ€èĄ“ăŻăƒ‡ă‚žă‚żăƒ«ăźæœȘæ„ă«ć‘ă‘ăŠSOSă«ć€‰ćŒ–ă‚’ă‚‚ăŸă‚‰ă—ăŸă—ăŸă€‚ + ă€Œă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăȘă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąă‚„æŠ€èĄ“ăŒçŸćœšæŽšé€Čă—ăŠă„ă‚‹ć€‰ćŒ–ăźé€ŸćșŠăŻé©šăăčăă‚‚ăźă§ă‚ă‚Šă€ăă‚Œă«èżœćŸ“ă—ăŠć°Žć…„ă™ă‚‹ă“ăšăŻç§ăŸăĄă«ăšăŁăŠéžćžžă«é‡èŠă§ă™ă€‚Kubernetesăšă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăŒæäŸ›ă™ă‚‹é©šăăčăæŠ€èĄ“ăŻăƒ‡ă‚žă‚żăƒ«ăźæœȘæ„ă«ć‘ă‘ăŠSOSă«ć€‰ćŒ–ă‚’ă‚‚ăŸă‚‰ă—ăŸă—ăŸă€‚

- SOS International ă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€… Martin Ahrentsen
@@ -49,16 +49,16 @@ logo: sos_featured_logo.png

SOS Internationalは60ćčŽă«ă‚ăŸă‚Šă€ćŒ—æŹ§è«žć›œăźéĄ§ćźąă«äżĄé Œæ€§ăźé«˜ă„ç·Šæ€„ćŒ»ç™‚ăŠă‚ˆăłæ—…èĄŒæ”ŻæŽă‚’æäŸ›ă—ăŠăăŸă—ăŸă€‚

SOSたă‚ȘăƒšăƒŹăƒŒă‚żăŻćčŽé–“100äž‡ä»¶ăźæĄˆä»¶ă‚’æ‰±ă„ă€100äž‡ä»¶ä»„äžŠăźé›»è©±ă‚’ć‡Šç†ă—ăŠă„ăŸă™ă€‚ă—ă‹ă—ă€éŽćŽ»4ćčŽé–“ă§ćŒç€Ÿăźăƒ“ă‚žăƒă‚čæˆŠç•„ă«ăƒ‡ă‚žă‚żăƒ«ç©șé–“ă§ăźăŸă™ăŸă™æż€ă—ă„é–‹ç™șăŒćż…èŠă«ăȘă‚ŠăŸă—ăŸă€‚

- ITă‚·ă‚čăƒ†ăƒ ă«é–ąă—ăŠă„ăˆă°ă€äŒšç€Ÿăźăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăƒŒă§çšŒćƒă™ă‚‹3ă€ăźäŒç”±çš„ăȘヱノăƒȘă‚čăšă‚Šă‚©ăƒŒă‚żăƒŒăƒ•ă‚©ăƒŒăƒ«ă‚ąăƒ—ăƒ­ăƒŒăƒă«ăŠă„ăŠă€ŒSOSăŻéžćžžă«æ–­ç‰‡ćŒ–ă•ă‚ŒăŸèł‡ç”ŁăŒă‚ă‚ŠăŸă™ă€‚ă€ăšă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€…ăźMartin Ahrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă‚’çŸ­çžźă—ă€ćŠčçŽ‡ă‚’é«˜ă‚ă‚‹ăŸă‚ă«æ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăšæ–°ă—ă„ćƒăæ–čた䞥æ–čă‚’ć°Žć…„ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă—ăŸă€‚ăă‚ŒăŻăŻă‚‹ă‹ă«æ©Ÿæ•ăȘă‚ąăƒ—ăƒ­ăƒŒăƒă§ă‚ă‚Šă€ăă‚Œă‚’ăƒ“ă‚žăƒă‚čă«æäŸ›ă™ă‚‹ăŸă‚ă«ćœčç«‹ă€ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒćż…èŠă§ă—ăŸă€‚ă€ + ITă‚·ă‚čăƒ†ăƒ ă«é–ąă—ăŠă„ăˆă°ă€äŒšç€Ÿăźăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăƒŒă§çšŒćƒă™ă‚‹3ă€ăźäŒç”±çš„ăȘヱノăƒȘă‚čăšă‚Šă‚©ăƒŒă‚żăƒŒăƒ•ă‚©ăƒŒăƒ«ă‚ąăƒ—ăƒ­ăƒŒăƒă«ăŠă„ăŠă€ŒSOSăŻéžćžžă«æ–­ç‰‡ćŒ–ă•ă‚ŒăŸèł‡ç”ŁăŒă‚ă‚ŠăŸă™ă€‚ă€ăšă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€…ăźMartin Ahrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă‚’çŸ­çžźă—ă€ćŠčçŽ‡ă‚’é«˜ă‚ă‚‹ăŸă‚ă«æ–°ă—ă„æŠ€èĄ“ăšæ–°ă—ă„ćƒăæ–čた䞥æ–čă‚’ć°Žć…„ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă—ăŸă€‚ăă‚ŒăŻăŻă‚‹ă‹ă«æ©Ÿæ•ăȘă‚ąăƒ—ăƒ­ăƒŒăƒă§ă‚ă‚Šă€ăă‚Œă‚’ăƒ“ă‚žăƒă‚čă«æäŸ›ă™ă‚‹ăŸă‚ă«ćœčç«‹ă€ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒćż…èŠă§ă—ăŸă€‚ă€

- Ahrentsenæ°ăšćœŒăźăƒăƒŒăƒ ăŻé•·ă„é–“SOSă§æ©Ÿèƒœă™ă‚‹æš™æș–ăźă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’æŽąă—ăŠă„ăŸă—ăŸă€‚ă€Œç§ăŸăĄăźă‚ˆă†ăȘæ”ŻæŽäŒšç€ŸăŻăă‚Œă»ă©ć€šăăȘă„ăźă§ă€ăă‚Œă«ă”ă•ă‚ă—ă„æš™æș–ă‚·ă‚čăƒ†ăƒ ă‚’ć…„æ‰‹ă™ă‚‹ă“ăšăŻă§ăăŸă›ă‚“ă€‚ćźŒć…šă«äž€è‡Žă™ă‚‹ă‚‚ăźăŒăȘă„ăźă§ă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€Œæš™æș–ă‚·ă‚čăƒ†ăƒ ă‚’æŽĄç”šă—ăŸăšă—ăŠă‚‚ă€ă‚ăŸă‚Šă«ă‚‚ăČă­ă‚Šă™ăŽăŠă€ă‚‚ăŻă‚„æš™æș–ではăȘいもたにăȘă‚‹ă§ă—ă‚‡ă†ă€‚ăăźăŸă‚ă€æ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚·ă‚čăƒ†ăƒ ăšă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’æ§‹çŻ‰ă™ă‚‹ăŸă‚ă«äœżç”šă§ăă‚‹ă„ăă€ă‹ăźć…±é€šă‚łăƒłăƒăƒŒăƒăƒłăƒˆă‚’ć‚™ăˆăŸăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚’èŠ‹ă€ă‘ă‚‹ă“ăšă«ă—ăŸă—ăŸă€‚ă€ + Ahrentsenæ°ăšćœŒăźăƒăƒŒăƒ ăŻé•·ă„é–“SOSă§æ©Ÿèƒœă™ă‚‹æš™æș–ăźă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’æŽąă—ăŠă„ăŸă—ăŸă€‚ă€Œç§ăŸăĄăźă‚ˆă†ăȘæ”ŻæŽäŒšç€ŸăŻăă‚Œă»ă©ć€šăăȘă„ăźă§ă€ăă‚Œă«ă”ă•ă‚ă—ă„æš™æș–ă‚·ă‚čăƒ†ăƒ ă‚’ć…„æ‰‹ă™ă‚‹ă“ăšăŻă§ăăŸă›ă‚“ă€‚ćźŒć…šă«äž€è‡Žă™ă‚‹ă‚‚ăźăŒăȘă„ăźă§ă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€Œæš™æș–ă‚·ă‚čăƒ†ăƒ ă‚’æŽĄç”šă—ăŸăšă—ăŠă‚‚ă€ă‚ăŸă‚Šă«ă‚‚ăČă­ă‚Šă™ăŽăŠă€ă‚‚ăŻă‚„æš™æș–ではăȘいもたにăȘă‚‹ă§ă—ă‚‡ă†ă€‚ăăźăŸă‚ă€æ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚·ă‚čăƒ†ăƒ ăšă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’æ§‹çŻ‰ă™ă‚‹ăŸă‚ă«äœżç”šă§ăă‚‹ă„ăă€ă‹ăźć…±é€šă‚łăƒłăƒăƒŒăƒăƒłăƒˆă‚’ć‚™ăˆăŸæŠ€èĄ“ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă‚’èŠ‹ă€ă‘ă‚‹ă“ăšă«ă—ăŸă—ăŸă€‚ă€
- ă€Œç§ăŸăĄăŻæ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă—ăȘければăȘă‚ŠăŸă›ă‚“ăŒă€ć€ă„ă‚‚ăźă‚‚ç§»èĄŒă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ăă—ăŠă€ă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠă«æ§‹çŻ‰ă•ă‚ŒăŸæ–°ă—ă„ă‚·ă‚čăƒ†ăƒ ă«ć€‰æ›ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ă“ăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’éžă‚“ă ç†ç”±ăź1ă€ăŻć€ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’ć€‰æ›Žă—ăȘăŒă‚‰æ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă§ăă‚‹ă‹ă‚‰ă§ă™ă€‚ă€ + ă€Œç§ăŸăĄăŻæ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă—ăȘければăȘă‚ŠăŸă›ă‚“ăŒă€ć€ă„ă‚‚ăźă‚‚ç§»èĄŒă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ăă—ăŠă€ă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠă«æ§‹çŻ‰ă•ă‚ŒăŸæ–°ă—ă„ă‚·ă‚čăƒ†ăƒ ă«ć€‰æ›ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ă“ăźæŠ€èĄ“ă‚’éžă‚“ă ç†ç”±ăź1ă€ăŻć€ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’ć€‰æ›Žă—ăȘăŒă‚‰æ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă§ăă‚‹ă‹ă‚‰ă§ă™ă€‚ă€

- SOS International ă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€… Martin Ahrentsen @@ -68,14 +68,14 @@ logo: sos_featured_logo.png
KubernetesăŒă§ăă‚‹ă“ăšă‚’ç†è§Łă™ă‚‹ăšă€Ahrentsenæ°ăŻă™ăă«ăƒ“ă‚žăƒă‚čăƒ‹ăƒŒă‚șをæș€ăŸă™ă“ăšăŒă§ăă‚‹ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ă«ç›źă‚’ć‘ă‘ăŸă—ăŸă€‚ćŒç€ŸăŻDockerコンテナべKubernetesă‚’ç”„ăżèŸŒă‚“ă Red HatたOpenShift Container Platformă‚’æŽĄç”šă—ăŸă—ăŸă€‚ăŸăŸă€RedHat Hyperconverged Infrastructureă‚„äž€éƒšăźăƒŸăƒƒăƒ‰ă‚Šă‚§ă‚ąă‚łăƒłăƒăƒŒăƒăƒłăƒˆăȘど、すăčおă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă§æäŸ›ă•ă‚ŒăŠă„ă‚‹æŠ€èĄ“ă‚čă‚żăƒƒă‚Żă‚‚ćˆ©ç”šă™ă‚‹ă“ăšă‚’æ±șă‚ăŸă—ăŸă€‚

- ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚„ă‚ąă‚žăƒȘăƒ†ă‚Łăźé©ćˆæ€§ă€æł•çš„èŠä»¶ă€ăŠă‚ˆăłă‚łăƒłăƒ”ăƒ†ăƒłă‚·ăƒŒăšă„ă†ćŒç€ŸăźćŸșæș–にćŸșă„ăăšă€OpenShiftă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăŻSOSăźæ–­ç‰‡ćŒ–ă•ă‚ŒăŸă‚·ă‚čăƒ†ăƒ ă«ćźŒć…šă«é©ćˆă™ă‚‹ă‚ˆă†ă«æ€ă‚ă‚ŒăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻă‚łăƒŒăƒ‰èš€èȘžăšăă‚Œä»„怖た䞥æ–čă‚’äœżç”šă™ă‚‹ć€šăăźç•°ăȘă‚‹æŠ€èĄ“ă‚’æŒăŁăŠă„ăŸă™ă€‚ăă‚Œă‚‰ăŻă™ăčăŠæ–°ă—ă„ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠăźăƒȘă‚œăƒŒă‚čă‚’äœżç”šă§ăăŸă™ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ćŒç€Ÿăź3ă€ăźăƒąăƒŽăƒȘă‚čăźă†ăĄă€ă€Œă“ăźæœ€ć…ˆç«Żăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’2぀(.NETずJava)ă«æäŸ›ă§ăăŸă™ă€‚ă€

+ æŠ€èĄ“ă‚„ă‚ąă‚žăƒȘăƒ†ă‚Łăźé©ćˆæ€§ă€æł•çš„èŠä»¶ă€ăŠă‚ˆăłă‚łăƒłăƒ”ăƒ†ăƒłă‚·ăƒŒăšă„ă†ćŒç€ŸăźćŸșæș–にćŸșă„ăăšă€OpenShiftă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăŻSOSăźæ–­ç‰‡ćŒ–ă•ă‚ŒăŸă‚·ă‚čăƒ†ăƒ ă«ćźŒć…šă«é©ćˆă™ă‚‹ă‚ˆă†ă«æ€ă‚ă‚ŒăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻă‚łăƒŒăƒ‰èš€èȘžăšăă‚Œä»„怖た䞥æ–čă‚’äœżç”šă™ă‚‹ć€šăăźç•°ăȘă‚‹æŠ€èĄ“ă‚’æŒăŁăŠă„ăŸă™ă€‚ăă‚Œă‚‰ăŻă™ăčăŠæ–°ă—ă„ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠăźăƒȘă‚œăƒŒă‚čă‚’äœżç”šă§ăăŸă™ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ćŒç€Ÿă«ă‚ă‚‹3ă€ăźăƒąăƒŽăƒȘă‚čぼ侭で、「2぀(.NETずJava)ă«ćŻŸă—ăŠă“ăźæœ€ć…ˆç«ŻăźæŠ€èĄ“ă‚’æäŸ›ă§ăăŸă™ă€‚ă€

ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻ2018ćčŽæ˜„ă«ć…Źé–‹ă•ă‚ŒăŸă—ăŸă€‚ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒă«ćŸșă„ă6぀たæœȘ開ç™șăźăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŒæœ€ćˆă«é–‹ć§‹ă•ă‚ŒăŸă—ăŸă€‚ă•ă‚‰ă«ă€ćŒç€ŸăźJavaケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăŻă™ăčど「ăƒȘフト&ă‚·ăƒ•ăƒˆă€ç§»èĄŒă‚’èĄŒăŁăŠă„ăŸă™ă€‚æœ€ćˆă«çšŒćƒă—ăŠă„ă‚‹Kubernetesăƒ™ăƒŒă‚čăźăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆăźäž€ă€ăŒRemote Medical Treatmentです。これは顧漱が音棰、チャット、ビデă‚Șを介しおSOSă‚ąăƒ©ăƒŒăƒ ă‚»ăƒłă‚żăƒŒă«é€Łç”Ąă§ăă‚‹ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă§ă™ă€‚ă€ŒćźŒć…šăȘCI/CDăƒ‘ă‚€ăƒ—ăƒ©ă‚€ăƒłăšæœ€æ–°ăźăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒă‚’ă™ăčお2぀たOpenShiftă‚Żăƒ©ă‚čă‚żăƒŒă‚»ăƒƒăƒˆă‚ąăƒƒăƒ—ă§ćźŸèĄŒă™ă‚‹ă“ăšă«ç„Šç‚čă‚’ćœ“ăŠăŠă€éžćžžă«çŸ­æ™‚é–“ă§é–‹ç™șă§ăăŸă—ăŸă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ćŒ—æŹ§è«žć›œăžăźăƒŹă‚čă‚­ăƒ„ăƒŒăƒˆăƒ©ăƒƒă‚ŻăźæŽŸéŁă«äœżç”šă•ă‚Œă‚‹Onsiteă€ăŠă‚ˆăłă€ăƒŹăƒƒă‚«ăƒŒè»Šăźèżœè·Ąă‚’ćŻèƒœă«ă™ă‚‹Follow Your Truckă‚‚ć±•é–‹ă•ă‚ŒăŠă„ăŸă™ă€‚
- ă€Œæ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§ITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€ + 「ITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæ–°ă—ă„æŠ€èĄ“ă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§æˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€

- SOS International ă‚šăƒłă‚żăƒŒăƒ—ăƒ©ă‚€ă‚șă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒèČŹä»»è€… Martin Ahrentsen
@@ -84,11 +84,11 @@ logo: sos_featured_logo.png
ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŒăŸă ă‚Șンプレミă‚čă§çšŒćƒă—ăŠă„ă‚‹ăźăŻă€äżé™șæ„­ç•ŒăźSOSăźéĄ§ćźąăźäž€éƒšăŻćŒç€ŸăŒăƒ‡ăƒŒă‚żă‚’ć‡Šç†ă—ăŠă„ă‚‹ăŸă‚ăŸă ă‚Żăƒ©ă‚Šăƒ‰æˆŠç•„ă‚’æŒăŁăŠă„ăȘいためです。KubernetesはSOSăŒăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăƒŒă§é–‹ć§‹ă—ă€ăƒ“ă‚žăƒă‚čたæș–ć‚™ăŒă§ăăŸă‚‰ă‚Żăƒ©ă‚Šăƒ‰ă«ç§»èĄŒă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ă€Œä»ŠćŸŒ35ćčŽă«ă‚ăŸăŁăŠă€ćœŒă‚‰ă™ăčăŠăŒæˆŠç•„ă‚’æŒăĄă€ăă—ăŠă€ăƒ‡ăƒŒă‚żă‚’ć–ă‚Šć‡șă—ăŠă‚Żăƒ©ă‚Šăƒ‰ă«ç§»èĄŒă§ăă‚‹ă§ă—ă‚‡ă†ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚æ©ŸćŻ†ăƒ‡ăƒŒă‚żăšéžæ©ŸćŻ†ăƒ‡ăƒŒă‚żăźăƒă‚€ăƒ–ăƒȘăƒƒăƒ‰ă‚Żăƒ©ă‚Šăƒ‰èš­ćźšă«ç§»èĄŒă™ă‚‹ćŻèƒœæ€§ă‚‚ă‚ă‚ŠăŸă™ă€‚

- SOSăźæŠ€èĄ“ăŻçąșă‹ă«éŽæžĄæœŸă«ă‚ă‚ŠăŸă™ă€‚ă€Œæ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ăŒă€ć€ă„ă‚‚ăźă‚‚ç§»èĄŒă™ă‚‹ćż…èŠăŒă‚ă‚Šă€ă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠă«æ§‹çŻ‰ă•ă‚ŒăŸæ–°ă—ă„ă‚·ă‚čăƒ†ăƒ ă«ć€‰æ›ă—ăȘければăȘă‚ŠăŸă›ă‚“ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œă“ăźăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’éžă‚“ă ç†ç”±ăź1ă€ăŻć€ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’ć€‰æ›Žă—ăȘăŒă‚‰æ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă§ăă‚‹ă‹ă‚‰ă§ă™ă€‚ă€

+ SOSăźæŠ€èĄ“ăŻçąșă‹ă«éŽæžĄæœŸă«ă‚ă‚ŠăŸă™ă€‚ă€Œæ–°ă—ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ăŒă€ć€ă„ă‚‚ăźă‚‚ç§»èĄŒă™ă‚‹ćż…èŠăŒă‚ă‚Šă€ă‚łă‚ąă‚·ă‚čăƒ†ăƒ ă‚’ă“ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ äžŠă«æ§‹çŻ‰ă•ă‚ŒăŸæ–°ă—ă„ă‚·ă‚čăƒ†ăƒ ă«ć€‰æ›ă—ăȘければăȘă‚ŠăŸă›ă‚“ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œă“ăźæŠ€èĄ“ă‚’éžă‚“ă ç†ç”±ăź1ă€ăŻć€ă„ăƒ‡ă‚žă‚żăƒ«ă‚”ăƒŒăƒ“ă‚čă‚’ć€‰æ›Žă—ăȘăŒă‚‰æ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’æ§‹çŻ‰ă§ăă‚‹ă‹ă‚‰ă§ă™ă€‚ă€

しかし、KubernetesăŻă™ă§ă«ćž‚ć ŽæŠ•ć…„ăŸă§ăźæ™‚é–“ă‚’çŸ­çžźă—ăŠăŠă‚Šă€ăăźă“ăšăŻă€æ–°èˆˆăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŒă„ă‹ă«èż…é€Ÿă«é–‹ç™șされ、ăƒȘăƒȘăƒŒă‚čă•ă‚ŒăŸă‹ă«ă‚‚èĄšă‚ŒăŠă„ăŸă™ă€‚ă€Œă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăźăƒȘăƒȘăƒŒă‚čæș–ć‚™ăŒă§ăăŠă‹ă‚‰ăƒȘăƒȘăƒŒă‚čćŻèƒœă«ăȘă‚‹ăŸă§ăźæ™‚é–“ăŻćŠ‡çš„ă«æ”čć–„ă•ă‚ŒăŸă—ăŸă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚

- ă•ă‚‰ă«ă€ă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łăźäž€ć“Ąă§ă‚ă‚‹ă“ăšăŻă€ă‚šăƒłă‚žăƒ‹ă‚ąă€ă‚ȘăƒšăƒŹăƒŒă‚żăƒŒă€ă‚ąăƒŒă‚­ăƒ†ă‚Żăƒˆăźæ•°ă‚’ä»ŠćčŽ60から100ă«ćą—ă‚„ă™ăšă„ă†ç›źæš™ă‚’èżœæ±‚ă™ă‚‹ă†ăˆă§ă€ćŒç€ŸăŒäșșæă‚’ćŒ•ăä»˜ă‘ă‚‹ăźă«ćœčç«‹ăĄăŸă—ăŸă€‚ă€ŒćœŒă‚‰ăŻă‚ŻăƒŒăƒ«ă§æ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’äœżă„ăŸă„ăšæ€ăŁăŠă„ăŸă™ă€‚ă€ăšAhrentsenăŻèš€ă„ăŸă™ă€‚ă€Œæ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§ITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€ + ă•ă‚‰ă«ă€ă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łăźäž€ć“Ąă§ă‚ă‚‹ă“ăšăŻă€ă‚šăƒłă‚žăƒ‹ă‚ąă€ă‚ȘăƒšăƒŹăƒŒă‚żăƒŒă€ă‚ąăƒŒă‚­ăƒ†ă‚Żăƒˆăźæ•°ă‚’ä»ŠćčŽ60から100ă«ćą—ă‚„ă™ăšă„ă†ç›źæš™ă‚’èżœæ±‚ă™ă‚‹ă†ăˆă§ă€ćŒç€ŸăŒäșșæă‚’ćŒ•ăä»˜ă‘ă‚‹ăźă«ćœčç«‹ăĄăŸă—ăŸă€‚ă€ŒćœŒă‚‰ăŻă‚ŻăƒŒăƒ«ă§æ–°ă—ă„æŠ€èĄ“ă‚’äœżă„ăŸă„ăšæ€ăŁăŠă„ăŸă™ă€‚ă€ăšAhrentsenăŻèš€ă„ăŸă™ă€‚ă€ŒITăƒ—ăƒ­ăƒ•ă‚§ăƒƒă‚·ăƒ§ăƒŠăƒ«ăŒæ–°ă—ă„æŠ€èĄ“ă‚’æäŸ›ă—ăŸăšă„ă†ç†ç”±ă§æˆ‘ăŒç€Ÿă‚’éžă‚“ă§ă„ăŸă“ăšăŒæ–°äșșç ”äżźăźæ™‚ă«ă‚ă‹ă‚ŠăŸă—ăŸă€‚ă€
@@ -105,6 +105,6 @@ logo: sos_featured_logo.png ä»ŁèĄšäŸ‹ïŒšè‡Șć‹•è»ŠăžăźIoTăźć°Žć…„ă€‚æŹ§ć·žć§”ć“ĄäŒšăŻçŸćœšă€ă™ăčăŠăźæ–°è»Šă«eCallă‚’èŁ…ć‚™ă™ă‚‹ă“ăšă‚’çŸ©ć‹™ă„ă‘ăŠă„ăŸă™ă€‚eCallăŻé‡ć€§ăȘäș€é€šäș‹æ•…ăŒç™șç”Ÿă—ăŸć Žćˆă«äœçœźă‚„ăăźä»–ăƒ‡ăƒŒă‚żă‚’é€äżĄă—ăŸă™ă€‚SOSăŻă“ăźă‚”ăƒŒăƒ“ă‚čをă‚čăƒžăƒŒăƒˆè‡Șć‹•æ”ŻæŽăšă—ăŠæäŸ›ă—ăŠă„ăŸă™ă€‚ă€Œé›»è©±ă‚’ć—ă‘ăŠă€ç·Šæ€„ćŻŸćżœăƒăƒŒăƒ ă‚’æŽŸéŁă™ă‚‹ćż…èŠăŒă‚ă‚‹ă‹ă©ă†ă‹ă€ăŸăŸăŻăă‚Œă»ă©ć€§ăăȘćœ±éŸżăŒăȘいどうかをçąșèȘă—ăŸă™ă€‚ă€ăšAhrentsenæ°ăŻèš€ă„ăŸă™ă€‚ă€Œă™ăčăŠăŒæŽ„ç¶šă•ă‚Œă€ăƒ‡ăƒŒă‚żă‚’é€äżĄă™ă‚‹æœȘæ„ăźäž–ç•ŒăŻă€æ–°ă—ă„ćž‚ć Žæ©ŸäŒšăšă„ă†ç‚čă§ç§ăŸăĄă«ăšăŁăŠć€§ăăȘćŻèƒœæ€§ă‚’ç”Ÿăżć‡șă—ăŸă™ă€‚ă—ă‹ă—ă€ăă‚ŒăŻăŸăŸITăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăšç§ăŸăĄăŒæäŸ›ă™ăčăă‚‚ăźă«ć€§ăăȘéœ€èŠă‚’ă‚‚ăŸă‚‰ă™ă§ă—ă‚‡ă†ă€‚ă€

- Ahrentsenæ°ăŻSOSăŒæŠ€èĄ“ăźéžæŠžă‚’èĄŒăŁăŠăăŸă“ăšă‚’è€ƒăˆă‚‹ăšă€ă“ăźèȘČéĄŒă«ććˆ†ćŻŸćżœă§ăă‚‹ăšæ„Ÿă˜ăŠă„ăŸă™ă€‚ă€Œă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăšăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŒçŸćœšæŽšé€Čă—ăŠă„ă‚‹ć€‰ćŒ–ăźé€ŸćșŠăŻé©šăăčăă‚‚ăźă§ă‚ă‚Šă€ăă‚Œă«èżœćŸ“ă—ăŠæŽĄç”šă™ă‚‹ă“ăšăŻç§ăŸăĄă«ăšăŁăŠéžćžžă«é‡èŠă§ă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesăšă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăŒæäŸ›ă™ă‚‹é©šăăčăăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŻă€ăƒ‡ă‚žă‚żăƒ«ăźæœȘæ„ă«ć‘ă‘ăŠSOSă«ć€‰ćŒ–ă‚’ă‚‚ăŸă‚‰ă—ć§‹ă‚ăŸă—ăŸă€‚ă€ + Ahrentsenæ°ăŻSOSăŒæŠ€èĄ“ăźéžæŠžă‚’èĄŒăŁăŠăăŸă“ăšă‚’è€ƒăˆă‚‹ăšă€ă“ăźèȘČéĄŒă«ććˆ†ćŻŸćżœă§ăă‚‹ăšæ„Ÿă˜ăŠă„ăŸă™ă€‚ă€Œă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăȘă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąă‚„æŠ€èĄ“ăŒçŸćœšæŽšé€Čă—ăŠă„ă‚‹ć€‰ćŒ–ăźé€ŸćșŠăŻé©šăăčăă‚‚ăźă§ă‚ă‚Šă€ăă‚Œă«èżœćŸ“ă—ăŠæŽĄç”šă™ă‚‹ă“ăšăŻç§ăŸăĄă«ăšăŁăŠéžćžžă«é‡èŠă§ă™ă€‚ă€ăšćœŒăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesăšă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăŒæäŸ›ă™ă‚‹é©šăăčăæŠ€èĄ“ăŻă€ăƒ‡ă‚žă‚żăƒ«ăźæœȘæ„ă«ć‘ă‘ăŠSOSă«ć€‰ćŒ–ă‚’ă‚‚ăŸă‚‰ă—ć§‹ă‚ăŸă—ăŸă€‚ă€
diff --git a/content/ja/case-studies/spotify/index.html b/content/ja/case-studies/spotify/index.html new file mode 100644 index 0000000000..0725723b68 --- /dev/null +++ b/content/ja/case-studies/spotify/index.html @@ -0,0 +1,120 @@ +--- +title: Spotifyă‚±ăƒŒă‚čă‚čタディ +linkTitle: Spotify +case_study_styles: true +cid: caseStudies +css: /css/style_case_studies.css +logo: spotify_featured_logo.png +featured: true +weight: 2 +quote: > + Kubernetesă‚’äž­ćżƒă«æˆé•·ă—ăŸçŽ æ™Žă‚‰ă—ă„ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚’èŠ‹ăŠă€ăăźäž€éƒšă«ăȘりたかったぼです。ă‚čăƒ”ăƒŒăƒ‰ăźć‘äžŠăšă‚łă‚čăƒˆć‰Šæž›ăźăƒĄăƒȘットをäș«ć—ă—ă€ăƒ™ă‚čăƒˆăƒ—ăƒ©ă‚Żăƒ†ă‚Łă‚čăšăƒ„ăƒŒăƒ«ă«ă€ă„ăŠæ„­ç•Œăźä»–ăźäŒæ„­ăšé€Łæșă—ăŸă„ăšă‚‚æ€ă„ăŸă—ăŸă€‚ +--- + +
+

ă‚±ăƒŒă‚čă‚čă‚żăƒ‡ă‚ŁïŒšSpotify
SpotifyïŒšă‚łăƒłăƒ†ăƒŠæŠ€èĄ“ăźă‚ąăƒŒăƒȘăƒŒă‚ąăƒ€ăƒ—ă‚żăƒŒă§ă‚ă‚‹Spotifyはè‡Șç€ŸèŁœă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłăƒ„ăƒŒăƒ«ă‹ă‚‰Kubernetesă«ç§»èĄŒă—ăŠă„ăŸă™ + +

+ +
+ +
+ äŒæ„­ć  Spotify     æ‰€ćœšćœ°  ă‚°ăƒ­ăƒŒăƒăƒ«     æ„­ç•Œ  ă‚šăƒłă‚żăƒŒăƒ†ă‚€ăƒĄăƒłăƒˆ +
+ +
+
+
+
+

èȘČ題

+ 2008ćčŽă‹ă‚‰ć§‹ăŸăŁăŸă‚ȘăƒŒăƒ‡ă‚Łă‚Șă‚čトăƒȘăƒŒăƒŸăƒłă‚°ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€ă‚ąă‚Żăƒ†ă‚Łăƒ–ăƒŠăƒŒă‚¶ăƒŒăŒäž–ç•Œäž­ă§æŻŽæœˆ2愄äșșă‚’è¶…ăˆă‚‹ăŸă§ă«æˆé•·ă—ăŸă—ăŸă€‚ă€Œç§ăŸăĄăźç›źæš™ăŻă€ă‚ŻăƒȘă‚šă‚€ă‚żăƒŒăŸăĄă«ćŠ›ă‚’äžŽăˆă€ç§ăŸăĄăŒçŸćœšæŠ±ăˆă‚‹ă™ăčăŠăźæ¶ˆèČ»è€…ă€ăă—ăŠéĄ˜ă‚ăă°ć°†æ„æŠ±ăˆă‚‹æ¶ˆèČ»è€…ăŒçœŸă«æČĄć…„ă§ăă‚‹éŸłæ„œäœ“éš“ă‚’ćźŸçŸă™ă‚‹ă“ăšă§ă™ă€ă€ă‚šăƒłă‚žăƒ‹ă‚ąăƒȘăƒłă‚°ă€ă‚€ăƒłăƒ•ăƒ©ăŠă‚ˆăłă‚ȘăƒšăƒŹăƒŒă‚·ăƒ§ăƒłæ‹…ćœ“ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒăźJai ChakrabartiăŻă€ă“ă†èš€ă„ăŸă™ă€‚ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čずDockerăźă‚ąăƒŒăƒȘăƒŒă‚ąăƒ€ăƒ—ă‚żăƒŒă§ă‚ă‚‹Spotifyは、Heliosべいうè‡Ș瀟開ç™șぼコンテナă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚·ă‚čăƒ†ăƒ ă‚’äœżă„ă€è‡Șç€ŸăźVMć…šäœ“ă«ă‚ăŸă‚ŠćźŸèĄŒă•ă‚Œă‚‹ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚’ă‚łăƒłăƒ†ăƒŠćŒ–ă—ăŠă„ăŸă—ăŸă€‚2017ćčŽæœ«ăŸă§ă«ăŻă€ă€Œă“ă†ă„ăŁăŸæ©Ÿèƒœé–‹ç™șにè‡Șç€Ÿăźć°ă•ăȘăƒăƒŒăƒ ă§ć–ă‚Šç”„ă‚€ă“ăšăŻćŠč率的ではăȘăă€ć€§ăăȘă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă§æ”ŻæŒă•ă‚ŒăŠă„ă‚‹ă‚‚ăźă‚’æŽĄç”šă—ăŸă»ă†ăŒă‚ˆă„ă€ă“ăšăŒăŻăŁăă‚Šă—ăŠăăŸă—ăŸă€‚ + +

+

ă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒł

+ 「Kubernetesă‚’äž­ćżƒă«æˆé•·ă—ăŸçŽ æ™Žă‚‰ă—ă„ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚’èŠ‹ăŠă€ăăźäž€éƒšă«ăȘりたかったぼです。」べChakrabartiăŻèš€ă„ăŸă™ă€‚KubernetesはHeliosă‚ˆă‚Šă‚‚è±ŠćŻŒăȘæ©Ÿèƒœă‚’æœ‰ă—ăŠă„ăŸă—ăŸă€‚ă•ă‚‰ă«ă€ă€Œă‚čăƒ”ăƒŒăƒ‰ăźć‘äžŠăšă‚łă‚čăƒˆć‰Šæž›ăźăƒĄăƒȘットをäș«ć—ă—ă€ăƒ™ă‚čăƒˆăƒ—ăƒ©ă‚Żăƒ†ă‚Łă‚čăšăƒ„ăƒŒăƒ«ă«ă€ă„ăŠæ„­ç•Œăźä»–ăźäŒæ„­ăšé€Łæșă—ăŸă„ăšă‚‚æ€ă„ăŸă—ăŸă€‚ă€ăŸăŸćœŒăźăƒăƒŒăƒ ăŻă€æŽ»ç™șăȘKubernetesă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă«ăăźçŸ„èŠ‹ă§ă‚łăƒłăƒˆăƒȘăƒ“ăƒ„ăƒŒăƒˆă—ă€ćœ±éŸżă‚’äžŽăˆă‚‹ă“ăšă‚‚æœ›ăżăŸă—ăŸă€‚HeliosăźçšŒćƒăšäžŠèĄŒă—ăŠèĄŒă‚ă‚ŒăŸăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăŻă€ă‚čăƒ ăƒŒă‚șă«ă™ă™ă‚ă‚‹ă“ăšăŒă§ăăŸă—ăŸă€‚ăă‚ŒăŻă€ŒKubernetesがHeliosă‚’èŁœćźŒă™ă‚‹ă‚‚ăźăšă—ăŠă€ăă—ăŠä»ŠăŻHeliosă‚’ä»Łæ›żă™ă‚‹ă‚‚ăźăšă—ăŠéžćžžă«ăƒ•ă‚Łăƒƒăƒˆă—ăŸă‚‚ăźă ăŁăŸă‹ă‚‰ă§ă™ă€ăšChakrabartiăŻèš€ă„ăŸă™ă€‚ + +

ă‚€ăƒłăƒ‘ă‚Żăƒˆ

+ 2018ćčŽăźćŸŒćŠă«ć§‹ăŸă‚Šă€2019ćčŽă«ć‘ă‘ăŠć€§ăăȘæłšćŠ›ç‚čずăȘă‚‹æœŹăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłă«ăŠă„ăŠćż…èŠăšăȘă‚‹äž»èŠăȘæŠ€èĄ“ăźć•éĄŒă«ćŻŸćżœă™ă‚‹ăŸă‚ă€ăƒăƒŒăƒ ăŻ2018ćčŽăźć€§ćŠă‚’èČ»ă‚„ă—ăŸă—ăŸă€‚ă€Œă»ă‚“ăźäž€éƒšă‚’Kubernetesă«ç§»èĄŒă—ăŸăźă§ă™ăŒă€ç€Ÿć†…ăƒăƒŒăƒ ă‹ă‚‰èžă“ăˆăŠăăŸăźăŻă€æ‰‹äœœæ„­ă§ăźă‚­ăƒŁăƒ‘ă‚·ăƒ†ă‚Łăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’æ„è­˜ă™ă‚‹ćż…èŠæ€§ăŒć°‘ăȘくăȘり、Spotifyăšă—ăŠăźæ©ŸèƒœăźæäŸ›ă«é›†äž­ă§ăă‚‹æ™‚é–“ăŒă‚ˆă‚Šć€šăăȘっどきたべいうこべです」べChakrabartiăŻèš€ă„ăŸă™ă€‚Kubernetesă§çŸćœšćźŸèĄŒă•ă‚ŒăŠă„ă‚‹æœ€ă‚‚ć€§ăăȘă‚”ăƒŒăƒ“ă‚čはケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłă‚”ăƒŒăƒ“ă‚čで、1秒あたり箄1000侇ăƒȘクスă‚čトを揗け揖り、ă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ«ă«ă‚ˆă‚‹ć€§ăăȘæ©æ”ă‚’ć—ă‘ăŠă„ă‚‹ă€ăšă‚”ă‚€ăƒˆăƒ»ăƒȘăƒ©ă‚€ă‚ąăƒ“ăƒȘăƒ†ă‚Łăƒ»ă‚šăƒłă‚žăƒ‹ă‚ąăźJames WenăŻèš€ă„ăŸă™ă€‚ă•ă‚‰ă«ă€ă€Œä»„ć‰ăŻăƒăƒŒăƒ ăŒæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’äœœă‚Šă€é‹ç”šăƒ›ă‚čăƒˆă‚’æœŹç•Șç’°ćąƒă§çšŒćƒă•ă›ă‚‹ăŸă‚ă«1æ™‚é–“ćŸ…ăŸăȘければăȘă‚ŠăŸă›ă‚“ă§ă—ăŸăŒă€Kubernetesă§ăŻç§’ăƒ»ćˆ†ăźă‚ȘăƒŒăƒ€ăƒŒă§ăă‚Œă‚’ćźŸçŸă§ăăŸă™ă€ăšä»˜ă‘ćŠ ăˆăŸă™ă€‚ă•ă‚‰ă«ă€Kubernetesăźăƒ“ăƒłăƒ‘ăƒƒă‚­ăƒłă‚°ïŒˆç”„ăżćˆă‚ă›æœ€é©ćŒ–ïŒ‰æ©Ÿèƒœă‚„ăƒžăƒ«ăƒăƒ†ăƒŠăƒłăƒˆæ©Ÿèƒœă«ă‚ˆă‚Šă€CPUäœżç”šçŽ‡ăŒćčłć‡ă—お2〜3ć€ć‘äžŠă—ăŸă—ăŸă€‚ + +
+
+
+
+
+ 「Kubernetesă‚’äž­ćżƒă«æˆé•·ă—ăŸçŽ æ™Žă‚‰ă—ă„ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚’èŠ‹ăŠă€ăăźäž€éƒšă«ăȘりたかったぼです。ă‚čăƒ”ăƒŒăƒ‰ăźć‘äžŠăšă‚łă‚čăƒˆć‰Šæž›ăźăƒĄăƒȘットをäș«ć—ă—ă€ăƒ™ă‚čăƒˆăƒ—ăƒ©ă‚Żăƒ†ă‚Łă‚čăšăƒ„ăƒŒăƒ«ă«ă€ă„ăŠæ„­ç•Œăźä»–ăźäŒæ„­ăšé€Łæșă—ăŸă„ăšă‚‚æ€ă„ăŸă—ăŸă€‚ă€

- Spotify スンゾニケăƒȘăƒłă‚°ă€ă‚€ăƒłăƒ•ăƒ©ăŠă‚ˆăłă‚ȘăƒšăƒŹăƒŒă‚·ăƒ§ăƒłæ‹…ćœ“ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒă€Jai Chakrabarti +
+
+
+
+

ă€Œç§ăŸăĄăźă‚ŽăƒŒăƒ«ăŻă€ă‚ŻăƒȘă‚šă‚€ă‚żăƒŒăŸăĄă«ćŠ›ă‚’äžŽăˆă€ä»Šăƒ»ă“ă‚Œă‹ă‚‰ăźæ¶ˆèČ»è€…ăŒçœŸă«æČĄć…„ă§ăă‚‹éŸłæ„œäœ“éš“ă‚’ćźŸçŸă™ă‚‹ă“ăšă§ă™ă€‚ă€SpotifyぼスンゾニケăƒȘăƒłă‚°ă€ă‚€ăƒłăƒ•ăƒ©ă‚čăƒˆăƒ©ă‚ŻăƒăƒŁăŠă‚ˆăłă‚ȘăƒšăƒŹăƒŒă‚·ăƒ§ăƒłæ‹…ćœ“ăƒ‡ă‚ŁăƒŹă‚Żă‚żăƒŒă€Jai ChakrabartiăŻă€ă“ăźă‚ˆă†ă«èż°ăčăŠă„ăŸă™ă€‚ +2008ćčŽă‹ă‚‰ć§‹ăŸăŁăŸă‚ȘăƒŒăƒ‡ă‚Łă‚Șă‚čトăƒȘăƒŒăƒŸăƒłă‚°ăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ăŻă€ă‚ąă‚Żăƒ†ă‚Łăƒ–ăƒŠăƒŒă‚¶ăƒŒăŒäž–ç•Œäž­ă§æŻŽæœˆ2愄äșșă‚’è¶…ăˆă‚‹ăŸă§ă«æˆé•·ă—ăŸă—ăŸă€‚ChakrabartiăźăƒăƒŒăƒ ă«ăšăŁăŠăźă‚ŽăƒŒăƒ«ăŻă€ć°†æ„ăźă™ăčăŠăźæ¶ˆèČ»è€…ă‚‚ă‚”ăƒăƒŒăƒˆă™ă‚‹ăčくSpotifyăźă‚€ăƒłăƒ•ăƒ©ă‚’ćŒ·ć›șăȘă‚‚ăźă«ă—ăŠă„ăă“ăšă§ă™ă€‚

+ +

+ ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čずDockerăźă‚ąăƒŒăƒȘăƒŒă‚ąăƒ€ăƒ—ă‚żăƒŒă§ă‚ă‚‹Spotifyは、è‡Șç€ŸăźVMć…šäœ“ă«ă‚ăŸă‚ŠćźŸèĄŒă•ă‚Œă‚‹ăƒžă‚€ă‚Żăƒ­ă‚”ăƒŒăƒ“ă‚čă‚’ă‚łăƒłăƒ†ăƒŠćŒ–ă—ăŠă„ăŸă—ăŸă€‚ćŒç€ŸăŻă€ŒHelios」べいうă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čたè‡Șç€ŸèŁœă‚łăƒłăƒ†ăƒŠă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚·ăƒ§ăƒłă‚·ă‚čăƒ†ăƒ ă‚’äœżç”šă—ă€2016ćčŽă‹ă‚‰17ćčŽă«ă‹ă‘おă‚Șンプレミă‚čăźăƒ‡ăƒŒă‚żă‚»ăƒłă‚żăƒŒă‹ă‚‰Google Cloudăžăźç§»èĄŒă‚’ćźŒäș†ă—ăŸă—ăŸă€‚ă“ă†ă„ăŁăŸæ„æ€æ±șćźšăźă€Œæˆ‘ă€…ă«ăŻă•ăŸă–ăŸăȘăƒ”ăƒŒă‚čă«ć–ă‚Šç”„ă‚€ă€ă™ă°ă‚„ăçč°ă‚Šèż”ă™äœœæ„­ă‚’ćż…èŠăšă™ă‚‹è‡ȘćŸ‹çš„ăȘスンゾニケăƒȘăƒłă‚°ăƒăƒŒăƒ ăŒ200ä»„äžŠă‚ă‚Šă€ćœŒă‚‰ă‚’äž­ćżƒăšă—ăŸæ–‡ćŒ–ăŒă‚ă‚ŠăŸă™ă€ăšChakrabartiăŻèš€ă„ăŸă™ă€‚ă€Œă—ăŸăŒăŁăŠă€ăƒăƒŒăƒ ăŒă™ă°ă‚„ăć‹•ă‘ă‚‹ă‚ˆă†ă«ăȘる開ç™șè€…ăźăƒ™ăƒ­ă‚·ăƒ†ă‚Łăƒ„ăƒŒăƒ«ă‚’æŒă€ă“ăšăŒéžćžžă«ć€§äș‹ă§ă™ă€‚ă€

しかし、2017ćčŽăźç”‚ă‚ă‚ŠăŸă§ă«ăŻă€ă€Œć°ă•ăȘăƒăƒŒăƒ ăŒHeliosăźæ©Ÿèƒœă«ć–ă‚Šç”„ă‚€ăźăŻă€ăă‚Œă‚ˆă‚Šă‚‚ăŻă‚‹ă‹ă«ć€§ăăȘă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă§æ”ŻæŒă•ă‚ŒăŠă„ă‚‹ă‚‚ăźăšæŻ”ăčるべćŠč率的ではăȘă„ă€ă“ăšăŒæ˜Žă‚‰ă‹ă«ăȘった、べChakrabartiăŻèš€ă„ăŸă™ă€‚ă€ŒKubernetesă‚’ć–ă‚Šć·»ăæˆé•·ă—ăŸé©šăăčăă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă‚’èŠ‹ăŸă—ăŸă€‚ăăźäž€ć“Ąă«ăȘă‚ŠăŸă„ăšæ€ă„ăŸă—ăŸă€‚ă‚čăƒ”ăƒŒăƒ‰ăźć‘äžŠăšă‚łă‚čăƒˆăźć‰Šæž›ă«ă‚ˆă‚‹æ©æ”ă‚’ć—ă‘ăŸă‹ăŁăŸă§ă™ă—ă€ăƒ™ă‚čăƒˆăƒ—ăƒ©ă‚Żăƒ†ă‚Łă‚čăšăƒ„ăƒŒăƒ«ă‚’ă‚‚ă€ä»–ăźæ„­ç•Œăšé€Łæșă—ăŸă„ăšă‚‚æ€ă„ăŸă—ăŸă€‚ă€ćŒæ™‚ă«ă“ăźăƒăƒŒăƒ ăŻă€æŽ»ç™șăȘKubernetesă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚Łă«ăăźçŸ„èŠ‹ă§ă‚łăƒłăƒˆăƒȘăƒ“ăƒ„ăƒŒăƒˆă—ă€ćœ±éŸżă‚’äžŽăˆă‚‹ă“ăšă‚‚æœ›ăżăŸă—ăŸă€‚ + + +
+
+
+
+ ă€Œă“ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻă€ă‚ă‚‰ă‚†ă‚‹æŠ€èĄ“ăžăźć–ă‚Šç”„ăżă‚’ă‚ˆă‚Šé€Ÿăă€ă‚ˆă‚Šćźčæ˜“ă«ă—ăŠăă‚Œă‚‹ă“ăšă‚’ćŒ·ćŠ›ă«ćŠ©ă‘ăŠăă‚ŒăŸă—ăŸă€‚ăă—ăŠă€ç§ăŸăĄăźć–ă‚Šç”„ăżăźă™ăčăŠă‚’æ€œèšŒă™ă‚‹ă“ăšă‚‚ćŠ©ă‘ăŠăă‚ŒăŸă—ăŸă€‚ă€

- Spotify ă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąă‚šăƒłă‚žăƒ‹ă‚ąă€ă‚€ăƒłăƒ•ăƒ©ăŠă‚ˆăłă‚ȘăƒšăƒŹăƒŒă‚·ăƒ§ăƒłæ‹…ćœ“ă€Dave Zolotusky + +
+
+
+
+ もう1ă€ăźăƒ—ăƒ©ă‚čïŒšă€ŒKubernetesがHeliosă‚’èŁœćźŒă™ă‚‹ă‚‚ăźăšă—ăŠă€ăă—ăŠä»ŠăŻHeliosă‚’ä»Łæ›żă™ă‚‹ă‚‚ăźăšă—ăŠéžćžžă«ăƒ•ă‚Łăƒƒăƒˆă—ăŸă‚‚ăźă ăŁăŸăźă§ă€ăƒȘă‚čă‚Żè»œæž›ăźăŸă‚ă«HeliosăšćŒæ™‚ă«çšŒćƒă•ă›ă‚‹ă“ăšăŒă§ăăŸă—ăŸă€ăšChakrabartiăŻèš€ă„ăŸă™ă€‚ă€Œăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăźæœ€äž­ăŻă‚”ăƒŒăƒ“ă‚čが価æ–čăźç’°ćąƒă§ćźŸèĄŒă•ă‚Œă‚‹ăźă§ă€ă•ăŸă–ăŸăȘèČ è·ăƒ»ă‚čトハă‚č環汃例でKubernetesăźæœ‰ćŠčæ€§ă‚’çąșèȘă§ăă‚‹ă‚ˆă†ă«ăȘă‚‹ăŸă§ăŻă™ăčăŠăźć”ă‚’1぀たバă‚čă‚±ăƒƒăƒˆă«ć…„ă‚Œă‚‹ćż…èŠăŒă‚ă‚ŠăŸă›ă‚“ă€‚ă€ + +

+ +ăƒăƒŒăƒ ăŻă€æœŹăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłă«ăŠă„ăŠćż…èŠăšăȘă‚‹äž»èŠăȘæŠ€èĄ“ăźć•éĄŒă«ćŻŸćżœă™ă‚‹ăŸă‚ă€ăƒăƒŒăƒ ăŻ2018ćčŽăźć€§ćŠă‚’èČ»ă‚„ă—ăŸă—ăŸă€‚ă€ŒăƒŹă‚Źă‚·ăƒŒăźă‚€ăƒłăƒ•ăƒ©ă‚’ă‚”ăƒăƒŒăƒˆă—ăŸă‚Šé€ŁæșするKubernetes APIやKubernetesăźæ‹ĄćŒ”æ€§æ©Ÿèƒœă‚’ć€šăäœżă†ă“ăšăŒă§ăăŸăźă§ă€ă‚€ăƒłăƒ†ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăŻă‚·ăƒłăƒ—ăƒ«ă§ç°Ąć˜ăȘă‚‚ăźă§ă—ăŸă€ăšă‚”ă‚€ăƒˆăƒ»ăƒȘăƒ©ă‚€ă‚ąăƒ“ăƒȘăƒ†ă‚Łăƒ»ă‚šăƒłă‚žăƒ‹ă‚ąăźJames WenăŻèš€ă„ăŸă™ă€‚ + +

+ăƒžă‚€ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăŻăăźćčŽăźćŸŒćŠă«ć§‹ăŸă‚Šă€2019ćčŽă«ćŠ é€Ÿă—ăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻă‚čăƒ†ăƒŒăƒˆăƒŹă‚čăȘă‚”ăƒŒăƒ“ă‚čă«æłšćŠ›ă—ăŠă„ăŸă™ă€‚æœ€ćŸŒă«æź‹ă‚‹æŠ€èĄ“çš„èȘČ題をçȘç Žă—ăŸă‚‰ă€ăă‚ŒăŒäžŠæ˜‡ă‚’ă‚‚ăŸă‚‰ă—ăŠăă‚Œă‚‹ăšæœŸćŸ…ă—ăŠă„ăŸă™ă€ăšChakrabartiăŻèš€ă„ăŸă™ă€‚ă€Œă‚čăƒ†ăƒŒăƒˆăƒ•ăƒ«ă‚”ăƒŒăƒ“ă‚čă«ă€ă„ăŠăŻă€ă‚ˆă‚Šć€šăăźă‚„ă‚‹ăčăă“ăšăŒă‚ă‚ŠăŸă™ă€‚ă€ +

+ä»Šăźăšă“ă‚ă€Spotifyた150ă‚’è¶…ăˆă‚‹ă‚”ăƒŒăƒ“ă‚čぼごく侀郹がKubernetesă«ç§»èĄŒă•ă‚ŒăŠă„ăŸă™ă€‚ + +ă€Œç€Ÿć†…ăźăƒăƒŒăƒ ă‹ă‚‰èžă“ăˆăŠăăŸăźăŻă€æ‰‹äœœæ„­ă§ăźă‚­ăƒŁăƒ‘ă‚·ăƒ†ă‚Łăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’æ„è­˜ă™ă‚‹ćż…èŠæ€§ăŒć°‘ăȘくăȘり、Spotifyăšă—ăŠăźæ©ŸèƒœăźæäŸ›ă«é›†äž­ă§ăă‚‹æ™‚é–“ăŒă‚ˆă‚Šć€šăăȘっどきたべいうこべです」べChakrabartiăŻèš€ă„ăŸă™ă€‚ + +Kubernetesă§çŸćœšćźŸèĄŒă•ă‚ŒăŠă„ă‚‹æœ€ă‚‚ć€§ăăȘă‚”ăƒŒăƒ“ă‚čはケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłă‚”ăƒŒăƒ“ă‚čで、1秒あたり箄1000侇ăƒȘクスă‚čトを揗け揖り、ă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ«ă«ă‚ˆă‚‹ć€§ăăȘæ©æ”ă‚’ć—ă‘ăŠă„ă‚‹ă€ăšWenăŻèš€ă„ăŸă™ă€‚ă•ă‚‰ă«ă€ă€Œä»„ć‰ăŻăƒăƒŒăƒ ăŒæ–°ă—ă„ă‚”ăƒŒăƒ“ă‚čă‚’äœœă‚Šă€é‹ç”šăƒ›ă‚čăƒˆă‚’æœŹç•Șç’°ćąƒă§çšŒćƒă•ă›ă‚‹ăŸă‚ă«1æ™‚é–“ćŸ…ăŸăȘければăȘă‚ŠăŸă›ă‚“ă§ă—ăŸăŒă€Kubernetesă§ăŻç§’ăƒ»ćˆ†ăźă‚ȘăƒŒăƒ€ăƒŒă§ăă‚Œă‚’ćźŸçŸă§ăăŸă™ă€ăšä»˜ă‘ćŠ ăˆăŸă™ă€‚ă•ă‚‰ă«ă€Kubernetesăźăƒ“ăƒłăƒ‘ăƒƒă‚­ăƒłă‚°ïŒˆç”„ăżćˆă‚ă›æœ€é©ćŒ–ïŒ‰æ©Ÿèƒœă‚„ăƒžăƒ«ăƒăƒ†ăƒŠăƒłăƒˆæ©Ÿèƒœă«ă‚ˆă‚Šă€CPUäœżç”šçŽ‡ăŒćčłć‡ă—お2〜3ć€ć‘äžŠă—ăŸă—ăŸă€‚ + + +
+
+
+
+ ă€ŒăƒŹă‚Źă‚·ăƒŒăźă‚€ăƒłăƒ•ăƒ©ă‚’ă‚”ăƒăƒŒăƒˆă—ăŸă‚Šé€ŁæșするKubernetes APIやKubernetesăźæ‹ĄćŒ”æ€§æ©Ÿèƒœă‚’ăŸăă•ă‚“äœżă†ă“ăšăŒă§ăăŸăźă§ă€ă‚€ăƒłăƒ†ă‚°ăƒŹăƒŒă‚·ăƒ§ăƒłăŻă‚·ăƒłăƒ—ăƒ«ă§ç°Ąć˜ăȘもぼでした」

- Spotify、Spotifyスンゾニケ、James Wen +
+
+ +
+
+ Chakrabartiは、SpotifyăŒèŠ‹ăŠă„ă‚‹4ă€ăźăƒˆăƒƒăƒ—ăƒŹăƒ™ăƒ«ăźăƒĄăƒˆăƒȘック - ăƒȘăƒŒăƒ‰ă‚żă‚€ăƒ ă€ăƒ‡ăƒ—ăƒ­ă‚€é »ćșŠă€äżźćŸ©æ™‚é–“ă€ăă—ăŠé‹ç”šèČ è· - ぼすăčăŠă«ă€ă„ăŠă€ŒKubernetesăŒă‚€ăƒłăƒ‘ă‚Żăƒˆă‚’äžŽăˆăŠă„ă‚‹ă€ăšæŒ‡æ‘˜ă—ăŸă™ă€‚ +

+KubernetesăŒćˆæœŸăźé ƒă«ć‡șăŠăăŸă‚”ă‚Żă‚»ă‚čă‚čăƒˆăƒŒăƒȘăƒŒăź1぀に、SpotifyăƒăƒŒăƒ ăŒKubernetesăźäžŠă«æ§‹çŻ‰ă—ăŸSlingshotăšă„ă†ăƒ„ăƒŒăƒ«ăŒă‚ă‚ŠăŸă™ă€‚ă€Œăƒ—ăƒ«ăƒȘクスă‚čトをć‡șすべ、24æ™‚é–“ćŸŒă«è‡Șć·±æ¶ˆæ»…ă™ă‚‹äž€æ™‚çš„ăȘă‚čăƒ†ăƒŒă‚žăƒłă‚°ç’°ćąƒă‚’ç”Ÿæˆă—ăŸă™ă€ăšChakrabartiăŻèš€ă„ăŸă™ă€‚ă€Œă“ă‚ŒăŻă™ăčおKubernetesăŒă‚„ăŁăŠăă‚ŒăŠă„ăŸă™ă€‚æ–°ă—ă„ăƒ†ă‚ŻăƒŽăƒ­ă‚žăƒŒăŒć‡șăŠăăŠäœżăˆă‚‹ă‚ˆă†ă«ăȘăŁăŸăšăă«ă€è‡Șćˆ†ăźă‚€ăƒĄăƒŒă‚žă‚’è¶…ăˆă‚‹ă‚ˆă†ăȘă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’ă„ă‹ă«ă—ăŠă“ăźç’°ćąƒäžŠă§äœœăŁăŠă„ăă‹ă€ăăźă‚„ă‚Šæ–čをç€șすćˆșæż€çš„ăȘäŸ‹ă ăšæ€ă„ăŸă™ă€‚ă€ +

+ăŸăŸSpotifyはgRPCずenvoyă‚’äœżă„ă€KubernetesăšćŒă˜ă‚ˆă†ă«ă€æ—ąć­˜ăźè‡Șç€ŸèŁœă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłă‚’çœźăæ›ăˆć§‹ă‚ăŸă—ăŸă€‚ă€Œç§ăŸăĄăŻăăźæ™‚ăźè‡Șćˆ†ăŸăĄăźèŠæšĄă‚’ç†ç”±ă«ă—ăŸé–‹ç™șă‚’ă—ăŠă„ăŠă€ćźŸéš›ă«ä»–ăźă‚œăƒȘăƒ„ăƒŒă‚·ăƒ§ăƒłăŻă‚ă‚ŠăŸă›ă‚“ă§ă—ăŸă€ăšă‚€ăƒłăƒ•ăƒ©ăŠă‚ˆăłé‹ç”šæ‹…ćœ“ăźă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąă‚šăƒłă‚žăƒ‹ă‚ąă§ă‚ă‚‹Dave ZolotuskyăŻèš€ă„ăŸă™ă€‚ă€Œă—ă‹ă—ă€ăă†ă„ăŁăŸèŠæšĄæ„Ÿăźăƒ„ăƒŒăƒ«ă§ă™ă‚‰ă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻç§ăŸăĄă«èżœă„ă€ăă€èżœă„è¶Šă—ăŠèĄŒăăŸă—ăŸă€‚ă€ + + +
+ +
+
+ ă€Œç§ăŸăĄăŒć–ă‚Šç”„ă‚“ă§ă„ă‚‹ă“ăšă«é–ąă™ă‚‹ć°‚é–€çŸ„è­˜ă‚’ćŸ—ă‚‹ăŸă‚ă«ă€ă‚łăƒłă‚żă‚Żăƒˆă—ăŸă„äșșăšé€Łç”Ąă‚’ć–ă‚‹ăźăŻé©šăă»ă©ç°Ąć˜ă§ă—ăŸă€‚ăă—ăŠă€ç§ăŸăĄăŒèĄŒăŁăŠă„ăŸă™ăčăŠăźæ€œèšŒă§ćœčç«‹ăĄăŸă—ăŸă€

- Spotifyă€ă‚”ă‚€ăƒˆăƒ»ăƒȘăƒ©ă‚€ă‚ąăƒ“ăƒȘăƒ†ă‚Łăƒ»ă‚šăƒłă‚žăƒ‹ă‚ąă€James Wen
+
+ + +
+ ă©ăĄă‚‰ăźæŠ€èĄ“ă‚‚æŽĄç”šă™ă‚‹ă«ăŻćˆæœŸæź”éšŽă§ăŻă‚ă‚ŠăŸă™ăŒă€ă€ŒgRPCはă‚čă‚­ăƒŒăƒžçźĄç†ă€APIèš­èšˆă€äž‹äœäș’æ›ăźć•éĄŒăȘă©ă€ćˆæœŸăźé–‹ç™șæź”éšŽă«ăŠă‘ă‚‹ć€šăăźć•éĄŒă«ćŻŸă—ăŠă‚ˆă‚ŠćŠ‡çš„ăȘćœ±éŸżă‚’äžŽăˆă‚‹ăšçąșäżĄă—ăŠă„ăŸă™ă€ăšZolotuskyăŻèš€ă„ăŸă™ă€‚ă€ŒăăźăŸă‚ă€ăă†ă„ăŁăŸé ˜ćŸŸă§gRPCă«ć‚Ÿć€’ă—ăŠă„ăŸă™ă€‚ă€ + +

+ăƒăƒŒăƒ ăŻSpotifyăźă‚Żăƒ©ă‚Šăƒ‰ăƒă‚€ăƒ†ă‚Łăƒ–ăȘă‚čă‚żăƒƒă‚Żă‚’æ‹Ąć€§ă—ç¶šă‘ăŠăŠă‚Š - ă“ăźæŹĄă«ă‚ă‚‹ăźăŻă‚čă‚żăƒƒă‚ŻăƒˆăƒŹăƒŒă‚·ăƒłă‚°ă§ă™ - CNCFăƒ©ăƒłăƒ‰ă‚čă‚±ăƒŒăƒ—ă‚’æœ‰ç”šăȘă‚Źă‚€ăƒ‰ăšă—ăŠæŽ»ç”šă—ăŠă„ăŸă™ă€‚ă€Œè§Łæ±șă™ă‚‹ćż…èŠăŒă‚ă‚‹ă‚‚ăźă‚’èŠ‹ăŸăšăă«ă€ă‚‚ă—ć€šæ•°ăźăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŒă‚ă‚Œă°ăă‚Œă‚‰ă‚’ćŒă˜ă‚ˆă†ă«è©•äŸĄă—ăŸă™ăŒă€ăăźăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŒCNCFăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆă§ă‚ă‚‹ă“ăšă«ăŻé–“é•ă„ăȘăäŸĄć€€ăŒă‚ă‚ŠăŸă™ă€ăšZolotuskyăŻèš€ă„ăŸă™ă€‚ + +

+SpotifyがKubernetesă§ă“ă‚ŒăŸă§ă«ç”Œéš“ă—ăŠăăŸă“ăšăŻăă‚Œă‚’èŁä»˜ă‘ăŠă„ăŸă™ă€‚ă€Œă‚ă‚‰ă‚†ă‚‹æŠ€èĄ“ă«ă‚ˆă‚Šé€Ÿăă‚ˆă‚Šç°Ąć˜ă«ć–ă‚Šç”„ă‚ă‚‹ă‚ˆă†ă«ăȘるç‚čă§ă€ă“ăźă‚łăƒŸăƒ„ăƒ‹ăƒ†ă‚ŁăŻæ„”ă‚ăŠæœ‰ç›Šă§ă™ă€ăšZolotuskyăŻèš€ă„ăŸă™ă€‚ă€Œç§ăŸăĄăŒć–ă‚Šç”„ă‚“ă§ă„ă‚‹ă“ăšă«é–ąă™ă‚‹ć°‚é–€çŸ„è­˜ă‚’ćŸ—ă‚‹ăŸă‚ă«ă€ă‚łăƒłă‚żă‚Żăƒˆă—ăŸă„äșșăšé€Łç”Ąă‚’ć–ă‚‹ăźăŻé©šăă»ă©ç°Ąć˜ă§ă—ăŸă€‚ăă—ăŠă€ç§ăŸăĄăŒèĄŒăŁăŠă„ăŸă™ăčăŠăźæ€œèšŒă§ćœčç«‹ăĄăŸă—ăŸă€‚ă€ + + +
+
+ + diff --git a/content/ja/case-studies/spotify/spotify-featured.svg b/content/ja/case-studies/spotify/spotify-featured.svg new file mode 100644 index 0000000000..fb7d8e750d --- /dev/null +++ b/content/ja/case-studies/spotify/spotify-featured.svg @@ -0,0 +1 @@ +kubernetes.io-logos \ No newline at end of file diff --git a/content/ja/case-studies/spotify/spotify_featured_logo.png b/content/ja/case-studies/spotify/spotify_featured_logo.png new file mode 100644 index 0000000000..def15c51bf Binary files /dev/null and b/content/ja/case-studies/spotify/spotify_featured_logo.png differ diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 62cc04cb7a..51442fd391 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -7,7 +7,7 @@ weight: 40 {{% capture overview %}} -æœŹă‚»ă‚Żă‚·ăƒ§ăƒłăŻă€Kubernetesă‚·ă‚čăƒ†ăƒ ăźć„ăƒ‘ăƒŒăƒˆăšă€ă‚Żăƒ©ă‚čă‚żăƒŒă‚’èĄšçŸă™ă‚‹ăŸă‚ă«KubernetesăŒäœżç”šă™ă‚‹æŠœè±ĄæŠ‚ćż”ă«ă€ă„ăŠć­Šçż’ă—ă€Kubernetesăźä»•ç”„ăżă‚’ă‚ˆă‚Šæ·±ăç†è§Łă™ă‚‹ăźă«ćœčç«‹ăĄăŸă™ă€‚ +æœŹă‚»ă‚Żă‚·ăƒ§ăƒłăŻă€Kubernetesă‚·ă‚čăƒ†ăƒ ăźć„ăƒ‘ăƒŒăƒˆăšă€{{< glossary_tooltip text="ă‚Żăƒ©ă‚čă‚żăƒŒ" term_id="cluster" length="all" >}}ă‚’èĄšçŸă™ă‚‹ăŸă‚ă«KubernetesăŒäœżç”šă™ă‚‹æŠœè±ĄæŠ‚ćż”ă«ă€ă„ăŠć­Šçż’ă—ă€Kubernetesăźä»•ç”„ăżă‚’ă‚ˆă‚Šæ·±ăç†è§Łă™ă‚‹ăźă«ćœčç«‹ăĄăŸă™ă€‚ {{% /capture %}} @@ -17,7 +17,7 @@ weight: 40 Kubernetesă‚’æ©Ÿèƒœă•ă›ă‚‹ă«ăŻă€*Kubernetes API ă‚Șブゾェクト* ă‚’äœżç”šă—ăŠă€ćźŸèĄŒă—ăŸă„ă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„ăăźä»–ăźăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ă€äœżç”šă™ă‚‹ă‚łăƒłăƒ†ăƒŠă‚€ăƒĄăƒŒă‚žă€ăƒŹăƒ—ăƒȘă‚«(è€‡èŁœ)ăźæ•°ă€ă©ă‚“ăȘăƒăƒƒăƒˆăƒŻăƒŒă‚Żă‚„ăƒ‡ă‚Łă‚čクăƒȘă‚œăƒŒă‚čă‚’ćˆ©ç”šćŻèƒœă«ă™ă‚‹ă‹ăȘă©ă€ă‚Żăƒ©ă‚čă‚żăƒŒăź *desired state* (æœ›ăŸă—ă„çŠ¶æ…‹)ă‚’èš˜èż°ă—ăŸă™ă€‚desired sate (æœ›ăŸă—ă„çŠ¶æ…‹)ă‚’ă‚»ăƒƒăƒˆă™ă‚‹ă«ăŻă€Kubernetes APIă‚’äœżç”šă—ăŠă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’äœœæˆă—ăŸă™ă€‚é€šćžžăŻă‚łăƒžăƒłăƒ‰ăƒ©ă‚€ăƒłă‚€ăƒłă‚żăƒŒăƒ•ă‚§ă‚€ă‚č `kubectl` を甹いどKubernetes APIă‚’æ“äœœă—ăŸă™ăŒă€Kubernetes APIă‚’ç›ŽæŽ„äœżç”šă—ăŠă‚Żăƒ©ă‚čă‚żăƒŒăšćŻŸè©±ă—ă€desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ă‚’èš­ćźšă€ăŸăŸăŻć€‰æ›Žă™ă‚‹ă“ăšă‚‚ă§ăăŸă™ă€‚ -䞀旊desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ă‚’èš­ćźšă™ă‚‹ăšă€*Kubernetes ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒł* ăŒćƒăă€ă‚Żăƒ©ă‚čă‚żăƒŒăźçŸćœšăźçŠ¶æ…‹ă‚’desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ă«äž€è‡Žă•ă›ăŸă™ă€‚ăăźăŸă‚ă«KubernetesăŻă•ăŸă–ăŸăȘタă‚čク(ăŸăšăˆă°ă€ă‚łăƒłăƒ†ăƒŠăźè”·ć‹•ăŸăŸăŻć†è”·ć‹•ă€ç‰č漚ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźăƒŹăƒ—ăƒȘă‚«æ•°ăźă‚čă‚±ăƒŒăƒȘング等)をè‡Șć‹•çš„ă«ćźŸèĄŒă—ăŸă™ă€‚Kubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ä»„äž‹ăźăƒ—ăƒ­ă‚»ă‚čă§æ§‹æˆă•ă‚ŒăŠă„ăŸă™ă€‚ +䞀旊desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ă‚’èš­ćźšă™ă‚‹ăšă€Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))ă‚’äœżç”šă—ăŸ*Kubernetes ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒł*ăŒæ©Ÿèƒœă—ă€ă‚Żăƒ©ă‚čă‚żăƒŒăźçŸćœšăźçŠ¶æ…‹ă‚’desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ă«äž€è‡Žă•ă›ăŸă™ă€‚ăăźăŸă‚ă«KubernetesăŻă•ăŸă–ăŸăȘタă‚čク(ăŸăšăˆă°ă€ă‚łăƒłăƒ†ăƒŠăźè”·ć‹•ăŸăŸăŻć†è”·ć‹•ă€ç‰č漚ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźăƒŹăƒ—ăƒȘă‚«æ•°ăźă‚čă‚±ăƒŒăƒȘング等)をè‡Șć‹•çš„ă«ćźŸèĄŒă—ăŸă™ă€‚Kubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ä»„äž‹ăźăƒ—ăƒ­ă‚»ă‚čă§æ§‹æˆă•ă‚ŒăŠă„ăŸă™ă€‚ * **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) た3ăƒ—ăƒ­ă‚»ă‚čăźé›†ćˆă§ă™ă€‚ă“ă‚Œă‚‰ăźăƒ—ăƒ­ă‚»ă‚čăŻă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźäž€ă€ăźăƒŽăƒŒăƒ‰äžŠă§ćźŸèĄŒă•ă‚ŒăŸă™ă€‚ćźŸèĄŒăƒŽăƒŒăƒ‰ăŻăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăšă—ăŠæŒ‡ćźšă—ăŸă™ă€‚ * ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźć€‹ă€…ăźéžăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăŻă€ăă‚Œăžă‚Œ2ă€ăźăƒ—ăƒ­ă‚»ă‚čă‚’ćźŸèĄŒă—ăŸă™ă€‚ @@ -26,7 +26,7 @@ Kubernetesă‚’æ©Ÿèƒœă•ă›ă‚‹ă«ăŻă€*Kubernetes API ă‚Șブゾェクト* ă‚’äœż ## Kubernetesă‚Șブゾェクト -Kubernetesă«ăŻă€ăƒ‡ăƒ—ăƒ­ă‚€æžˆăżăźă‚łăƒłăƒ†ăƒŠćŒ–ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„ăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ă€é–ąé€Łă™ă‚‹ăƒăƒƒăƒˆăƒŻăƒŒă‚Żăšăƒ‡ă‚Łă‚čクăƒȘă‚œăƒŒă‚čă€ă‚Żăƒ©ă‚čă‚żăƒŒăŒäœ•ă‚’ă—ăŠă„ă‚‹ă‹ă«é–ąă™ă‚‹ăăźä»–ăźæƒ…ć ±ăšă„ăŁăŸă€ă‚·ă‚čăƒ†ăƒ ăźçŠ¶æ…‹ă‚’èĄšçŸă™ă‚‹æŠœè±ĄăŒć«ăŸă‚ŒăŠă„ăŸă™ă€‚ă“ă‚Œă‚‰ăźæŠœè±ĄăŻă€Kubernetes APIたă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ă‚ˆăŁăŠèĄšçŸă•ă‚ŒăŸă™ă€‚è©łçŽ°ă«ă€ă„ăŠăŻă€[Kubernetesă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆæŠ‚èŠ](/docs/concepts/abstractions/overview/) ă‚’ă”èŠ§ăă ă•ă„ă€‚ +Kubernetesă«ăŻă€ăƒ‡ăƒ—ăƒ­ă‚€æžˆăżăźă‚łăƒłăƒ†ăƒŠćŒ–ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„ăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ă€é–ąé€Łă™ă‚‹ăƒăƒƒăƒˆăƒŻăƒŒă‚Żăšăƒ‡ă‚Łă‚čクăƒȘă‚œăƒŒă‚čă€ă‚Żăƒ©ă‚čă‚żăƒŒăŒäœ•ă‚’ă—ăŠă„ă‚‹ă‹ă«é–ąă™ă‚‹ăăźä»–ăźæƒ…ć ±ăšă„ăŁăŸă€ă‚·ă‚čăƒ†ăƒ ăźçŠ¶æ…‹ă‚’èĄšçŸă™ă‚‹æŠœè±ĄăŒć«ăŸă‚ŒăŠă„ăŸă™ă€‚ă“ă‚Œă‚‰ăźæŠœè±ĄăŻă€Kubernetes APIたă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ă‚ˆăŁăŠèĄšçŸă•ă‚ŒăŸă™ă€‚è©łçŽ°ă«ă€ă„ăŠăŻă€[Kubernetesă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ă€ă„ăŠçŸ„ă‚‹](/docs/concepts/overview/working-with-objects/kubernetes-objects/)ă‚’ă”èŠ§ăă ă•ă„ă€‚ ćŸșæœŹçš„ăȘKubernetesたă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŻæŹĄăźăšăŠă‚Šă§ă™ă€‚ @@ -35,19 +35,19 @@ Kubernetesă«ăŻă€ăƒ‡ăƒ—ăƒ­ă‚€æžˆăżăźă‚łăƒłăƒ†ăƒŠćŒ–ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒ * [Volume](/docs/concepts/storage/volumes/) * [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/) -äžŠèš˜ă«ćŠ ăˆă€Kubernetesă«ăŻă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšć‘Œă°ă‚Œă‚‹ć€šăăźé«˜ăƒŹăƒ™ăƒ«ăźæŠœè±ĄæŠ‚ćż”ăŒć«ăŸă‚ŒăŠă„ăŸă™ă€‚ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻćŸșæœŹă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ćŸșă„ă„ăŠæ§‹çŻ‰ă•ă‚Œă€ä»„äž‹ăźă‚ˆă†ăȘèżœćŠ ăźæ©ŸèƒœăšäŸżćˆ©ăȘæ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ +Kubernetesには、[ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/architecture/controller/)ă«äŸć­˜ă—ăŠćŸșæœŹă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’æ§‹çŻ‰ă—ă€èżœćŠ ăźæ©ŸèƒœăšäŸżćˆ©ăȘæ©Ÿèƒœă‚’æäŸ›ă™ă‚‹é«˜ăƒŹăƒ™ăƒ«ăźæŠœè±ĄćŒ–ă‚‚ć«ăŸă‚ŒăŠă„ăŸă™ă€‚ă“ă‚Œă‚‰ă«ăŻä»„äž‹ăźă‚‚ăźă‚’ć«ăżăŸă™: -* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/) * [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## Kubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒł Kubernetesマă‚čă‚żăƒŒă‚„ kubeletăƒ—ăƒ­ă‚»ă‚čべいったKubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăźă•ăŸă–ăŸăȘăƒ‘ăƒŒăƒ„ăŻă€KubernetesăŒă‚Żăƒ©ă‚čă‚żăƒŒăšă©ăźă‚ˆă†ă«é€šäżĄă™ă‚‹ă‹ă‚’ç”±ćˆ¶ă—ăŸă™ă€‚ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăŻă‚·ă‚čテム憅ぼすăčおたKubernetesă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźèš˜éŒČă‚’äżæŒă—ă€ăă‚Œă‚‰ăźă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăźçŠ¶æ…‹ă‚’çźĄç†ă™ă‚‹ăŸă‚ă«ç¶™ç¶šçš„ćˆ¶ćŸĄăƒ«ăƒŒăƒ—ă‚’ćźŸèĄŒă—ăŸă™ă€‚ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăźćˆ¶ćŸĄăƒ«ăƒŒăƒ—ăŻćžžă«ă‚Żăƒ©ă‚čă‚żăƒŒăźć€‰æ›Žă«ććżœă—ă€ă‚·ă‚čテム憅ぼすăčおたă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăźćźŸéš›ăźçŠ¶æ…‹ăŒă€æŒ‡ćźšă—ăŸçŠ¶æ…‹ă«äž€è‡Žă™ă‚‹ă‚ˆă†ă«ć‹•äœœă—ăŸă™ă€‚ -たべえば、Kubernetes APIă‚’äœżç”šă—ăŠDeploymentă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’äœœæˆă™ă‚‹ć Žćˆă€ă‚·ă‚čăƒ†ăƒ ă«ăŻæ–°ă—ă„desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ăŒæäŸ›ă•ă‚ŒăŸă™ă€‚Kubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăŻă€ăăźă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźäœœæˆă‚’èš˜éŒČă—ăŸă™ă€‚ăă—ăŠă€èŠæ±‚ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźé–‹ć§‹ă€ăŠă‚ˆăłă‚Żăƒ©ă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăžăźă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°ă«ă‚ˆă‚ŠæŒ‡ç€șă‚’ćźŒé‚ă—ăŸă™ă€‚ă“ăźă‚ˆă†ă«ă—ăŠă‚Żăƒ©ă‚čă‚żăƒŒăźćźŸéš›ăźçŠ¶æ…‹ă‚’æœ›ăŸă—ă„çŠ¶æ…‹ă«äž€è‡Žă•ă›ăŸă™ă€‚ +たべえば、Kubernetes APIă‚’äœżç”šă—ăŠDeploymentă‚’äœœæˆă™ă‚‹ć Žćˆă€ă‚·ă‚čăƒ†ăƒ ă«ăŻæ–°ă—ă„desired state (æœ›ăŸă—ă„çŠ¶æ…‹)ăŒæäŸ›ă•ă‚ŒăŸă™ă€‚Kubernetesă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ—ăƒŹăƒŒăƒłăŻă€ăăźă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźäœœæˆă‚’èš˜éŒČă—ăŸă™ă€‚ăă—ăŠă€èŠæ±‚ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźé–‹ć§‹ă€ăŠă‚ˆăłă‚Żăƒ©ă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăžăźă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°ă«ă‚ˆă‚ŠæŒ‡ç€șă‚’ćźŒé‚ă—ăŸă™ă€‚ă“ăźă‚ˆă†ă«ă—ăŠă‚Żăƒ©ă‚čă‚żăƒŒăźćźŸéš›ăźçŠ¶æ…‹ă‚’æœ›ăŸă—ă„çŠ¶æ…‹ă«äž€è‡Žă•ă›ăŸă™ă€‚ ### Kubernetesマă‚čă‚żăƒŒ @@ -59,11 +59,6 @@ Kubernetesぼマă‚čă‚żăƒŒăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒăźæœ›ăŸă—ă„çŠ¶æ…‹ă‚’ç¶­æŒă™ ă‚Żăƒ©ă‚čă‚żăƒŒăźăƒŽăƒŒăƒ‰ăŻă€ă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăšă‚Żăƒ©ă‚Šăƒ‰ăƒŻăƒŒă‚Żăƒ•ăƒ­ăƒŒă‚’ćźŸèĄŒă™ă‚‹ăƒžă‚·ăƒł(VMă€ç‰©ç†ă‚”ăƒŒăƒăƒŒăȘど)です。Kubernetesぼマă‚čă‚żăƒŒăŻć„ăƒŽăƒŒăƒ‰ă‚’ćˆ¶ćŸĄă—ăŸă™ă€‚é‹ç”šè€…è‡Șèș«ăŒăƒŽăƒŒăƒ‰ăšç›ŽæŽ„ćŻŸè©±ă™ă‚‹ă“ăšăŻă»ăšă‚“ă©ă‚ă‚ŠăŸă›ă‚“ă€‚ -#### ă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăƒĄă‚żăƒ‡ăƒŒă‚ż - - -* [Annotations](/ja/docs/concepts/overview/working-with-objects/annotations/) - {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ja/docs/concepts/architecture/_index.md b/content/ja/docs/concepts/architecture/_index.md index 9a275dbb90..69fda32def 100644 --- a/content/ja/docs/concepts/architecture/_index.md +++ b/content/ja/docs/concepts/architecture/_index.md @@ -1,4 +1,4 @@ --- -title: "Kubernetes ă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒ" +title: "Kubernetesăźă‚ąăƒŒă‚­ăƒ†ă‚ŻăƒăƒŁăƒŒ" weight: 30 --- diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index fb8894ba0c..a35674840f 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -47,7 +47,7 @@ kubectl describe node <ăƒŽăƒŒăƒ‰ć> | `Ready` | ăƒŽăƒŒăƒ‰ăźçŠ¶æ…‹ăŒHealthyでPodă‚’é…çœźćŻèƒœăȘ栎搈に`True`にăȘă‚ŠăŸă™ă€‚ăƒŽăƒŒăƒ‰ăźçŠ¶æ…‹ă«ć•éĄŒăŒă‚ă‚Šă€PodăŒé…çœźă§ăăȘă„ć Žćˆă«`False`にăȘă‚ŠăŸă™ă€‚ăƒŽăƒŒăƒ‰ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒă€`node-monitor-grace-period`ă§èš­ćźšă•ă‚ŒăŸæ™‚é–“ć†…(ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻ40秒)にè©Čćœ“ăƒŽăƒŒăƒ‰ăšç–Žé€šă§ăăȘい栮搈、`Unknown`にăȘă‚ŠăŸă™ă€‚ | | `MemoryPressure` | ăƒŽăƒŒăƒ‰ăźăƒĄăƒąăƒȘăŒćœ§èż«ă•ă‚ŒăŠă„ă‚‹ăšăă«`True`にăȘă‚ŠăŸă™ă€‚ćœ§èż«ăšăŻă€ăƒĄăƒąăƒȘたç©șきćźč量が民ăȘă„ă“ăšă‚’æŒ‡ă—ăŸă™ă€‚ăă‚Œä»„ć€–ăźăšăăŻ`False`です。 | | `PIDPressure` | ăƒ—ăƒ­ă‚»ă‚čăŒćœ§èż«ă•ă‚ŒăŠă„ă‚‹ăšăă«`True`にăȘă‚ŠăŸă™ă€‚ćœ§èż«ăšăŻă€ăƒ—ăƒ­ă‚»ă‚čæ•°ăŒć€šă™ăŽă‚‹ă“ăšă‚’æŒ‡ă—ăŸă™ă€‚ăă‚Œä»„ć€–ăźăšăăŻ`False`です。 | -| `DiskPressure` | ăƒŽăƒŒăƒ‰ăźăƒ‡ă‚Łă‚čクćźčé‡ăŒăŒćœ§èż«ă•ă‚ŒăŠă„ă‚‹ăšăă«`True`にăȘă‚ŠăŸă™ă€‚ćœ§èż«ăšăŻă€ăƒ‡ă‚Łă‚čクぼç©șきćźč量が民ăȘă„ă“ăšă‚’æŒ‡ă—ăŸă™ă€‚ăă‚Œä»„ć€–ăźăšăăŻ`False`です。 | +| `DiskPressure` | ăƒŽăƒŒăƒ‰ăźăƒ‡ă‚Łă‚čクćźčé‡ăŒćœ§èż«ă•ă‚ŒăŠă„ă‚‹ăšăă«`True`にăȘă‚ŠăŸă™ă€‚ćœ§èż«ăšăŻă€ăƒ‡ă‚Łă‚čクぼç©șきćźč量が民ăȘă„ă“ăšă‚’æŒ‡ă—ăŸă™ă€‚ăă‚Œä»„ć€–ăźăšăăŻ`False`です。 | | `NetworkUnavailable` | ăƒŽăƒŒăƒ‰ăźăƒăƒƒăƒˆăƒŻăƒŒă‚ŻăŒé©ćˆ‡ă«èš­ćźšă•ă‚ŒăŠă„ăȘă„ć Žćˆă«`True`にăȘă‚ŠăŸă™ă€‚ăă‚Œä»„ć€–ăźăšăăŻ`False`です。 | ăƒŽăƒŒăƒ‰ăźConditionはJSONă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă§èĄšçŸă•ă‚ŒăŸă™ă€‚äŸ‹ăˆă°ă€æ­ŁćžžăȘăƒŽăƒŒăƒ‰ăźć ŽćˆăŻä»„äž‹ăźă‚ˆă†ăȘハă‚čポンă‚čăŒèĄšç€șă•ă‚ŒăŸă™ă€‚ diff --git a/content/ja/docs/concepts/cluster-administration/_index.md b/content/ja/docs/concepts/cluster-administration/_index.md new file mode 100755 index 0000000000..39996efb33 --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,5 @@ +--- +title: "ă‚Żăƒ©ă‚čă‚żăƒŒăźçźĄç†" +weight: 100 +--- + diff --git a/content/ja/docs/concepts/configuration/_index.md b/content/ja/docs/concepts/configuration/_index.md new file mode 100755 index 0000000000..32113b0ea0 --- /dev/null +++ b/content/ja/docs/concepts/configuration/_index.md @@ -0,0 +1,5 @@ +--- +title: "èš­ćźš" +weight: 80 +--- + diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index ad442f3ab3..3e1c30f9b8 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -1,5 +1,4 @@ --- -title: "Containers" +title: "コンテナ" weight: 40 --- - diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md new file mode 100644 index 0000000000..f83bc9ebc5 --- /dev/null +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -0,0 +1,223 @@ +--- +title: ă‚«ă‚čタムăƒȘă‚œăƒŒă‚č +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +*ă‚«ă‚čタムăƒȘă‚œăƒŒă‚č* はKubernetes APIăźæ‹ĄćŒ”ă§ă™ă€‚ă“ăźăƒšăƒŒă‚žă§ăŻă€ă„ă€Kubernetesăźă‚Żăƒ©ă‚čă‚żăƒŒă«ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’èżœćŠ ă™ă‚‹ăčきăȘăźă‹ă€ăă—ăŠă„ă€ă‚čă‚żăƒłăƒ‰ă‚ąăƒ­ăƒŒăƒłăźă‚”ăƒŒăƒ“ă‚čă‚’ćˆ©ç”šă™ă‚‹ăčきăȘăźă‹ă‚’è­°è«–ă—ăŸă™ă€‚ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’èżœćŠ ă™ă‚‹2぀たæ–čæł•ăšă€ăă‚Œă‚‰ăźéžæŠžæ–čæł•ă«ă€ă„ăŠèȘŹæ˜Žă—ăŸă™ă€‚ + +{{% /capture %}} + +{{% capture body %}} + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚č + +*ăƒȘă‚œăƒŒă‚č* は、[Kubernetes API](/docs/reference/using-api/api-overview/)ăźă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă§ă€ç‰č漚ぼ[APIă‚Șブゾェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)ăźă‚łăƒŹă‚Żă‚·ăƒ§ăƒłă‚’äżæŒă—ăŸă™ă€‚äŸ‹ăˆă°ă€ăƒ“ăƒ«ăƒˆă‚€ăƒłăź *Pods* ăƒȘă‚œăƒŒă‚čは、Podă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźă‚łăƒŹă‚Żă‚·ăƒ§ăƒłă‚’ćŒ…ć«ă—ăŠă„ăŸă™ă€‚ + +*ă‚«ă‚čタムăƒȘă‚œăƒŒă‚č* は、Kubernetes APIăźæ‹ĄćŒ”ă§ă€ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźKubernetesă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă§ăŻă€ćż…ăšă—ă‚‚ćˆ©ç”šă§ăă‚‹ăšăŻé™ă‚ŠăŸă›ă‚“ă€‚ă€ăŸă‚Šăă‚ŒăŻă€ç‰č漚ぼKubernetesă‚€ăƒłă‚čăƒˆăƒŒăƒ«ăźă‚«ă‚čă‚żăƒžă‚€ă‚șă‚’èĄšă—ăŸă™ă€‚ă—ă‹ă—ă€ä»ŠçŸćœšă€ć€šæ•°ăźKubernetesăźă‚łă‚ąæ©ŸèƒœăŻă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’ç”šă„ăŠäœœă‚‰ă‚ŒăŠăŠă‚Šă€Kubernetesă‚’ăƒąă‚žăƒ„ăƒŒăƒ«ćŒ–ă—ăŠă„ăŸă™ă€‚ + +ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăŻă€çšŒćƒă—ăŠă„ă‚‹ă‚Żăƒ©ă‚čă‚żăƒŒă«ć‹•çš„ă«ç™»éŒČă•ă‚Œă€çŸă‚ŒăŸă‚Šă€æ¶ˆăˆăŸă‚Šă—ă€ă‚Żăƒ©ă‚čă‚żăƒŒçźĄç†è€…ăŻă‚Żăƒ©ă‚čă‚żăƒŒè‡Șäœ“ăšăŻç„Ąé–ąäż‚ă«ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’æ›Žæ–°ă§ăăŸă™ă€‚äž€ćșŠă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăŒă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă•ă‚Œă‚‹ăšă€ăƒŠăƒŒă‚¶ăƒŒăŻ[kubectl](/docs/user-guide/kubectl-overview/)ă‚’äœżă„ă€ăƒ“ăƒ«ăƒˆă‚€ăƒłăźăƒȘă‚œăƒŒă‚čである *Pods* ăšćŒă˜ă‚ˆă†ă«ă€ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’äœœæˆă€ă‚ąă‚Żă‚»ă‚čă™ă‚‹ă“ăšăŒćŻèƒœă§ă™ă€‚ + +## ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ + +ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čそれè‡Șèș«ăŻă€ć˜çŽ”ă«æ§‹é€ ćŒ–ăƒ‡ăƒŒă‚żă‚’æ ŒçŽă€ć–ă‚Šć‡șă™æ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čを *ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ* ăšç”„ăżćˆă‚ă›ă‚‹ă“ăšă§ă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čは真ぼ _ćźŁèš€çš„API_ ă‚’æäŸ›ă—ăŸă™ă€‚ + +[ćźŁèš€çš„API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’ç†è§Łă™ă‚‹)は、ăƒȘă‚œăƒŒă‚čぼあるăčăçŠ¶æ…‹ă‚’ _ćźŁèš€_ ăŸăŸăŻæŒ‡ćźšă™ă‚‹ă“ăšă‚’ćŻèƒœă«ă—ă€Kubernetesă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăźçŸćœšăźçŠ¶æ…‹ă‚’ă€ă‚ă‚‹ăčăçŠ¶æ…‹ă«ćŒæœŸă—ç¶šă‘ă‚‹ă‚ˆă†ă«ć‹•ăăŸă™ă€‚ +ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă€æ§‹é€ ćŒ–ăƒ‡ăƒŒă‚żă‚’ăƒŠăƒŒă‚¶ăƒŒăŒæŒ‡ćźšă—ăŸă‚ă‚‹ăčăçŠ¶æ…‹ăšè§Łé‡ˆă—ă€ăăźçŠ¶æ…‹ă‚’çźĄç†ă—ç¶šă‘ăŸă™ă€‚ + +çšŒćƒă—ăŠă„ă‚‹ă‚Żăƒ©ă‚čă‚żăƒŒăźăƒ©ă‚€ăƒ•ă‚”ă‚€ă‚Żăƒ«ăšăŻç„Ąé–ąäż‚ă«ă€ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă€æ›Žæ–°ă™ă‚‹ă“ăšăŒćŻèƒœă§ă™ă€‚ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă‚ă‚‰ă‚†ă‚‹ăƒȘă‚œăƒŒă‚čべ連æșă§ăăŸă™ăŒă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăšç”„ăżćˆă‚ă›ă‚‹ăšç‰čにćŠčæžœă‚’ç™șæźă—ăŸă™ă€‚[ă‚ȘăƒšăƒŹăƒŒă‚żăƒŒăƒ‘ă‚żăƒŒăƒł](https://coreos.com/blog/introducing-operators.html)は、カă‚čタムăƒȘă‚œăƒŒă‚čずカă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźç”„ăżćˆă‚ă›ă§ă™ă€‚ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆă‚Šă€ç‰č漚ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźăƒ‰ăƒĄă‚€ăƒłçŸ„è­˜ă‚’ă€Kubernetes APIăźæ‹ĄćŒ”ă«ć€‰æ›ă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’ă‚Żăƒ©ă‚čă‚żăƒŒă«èżœćŠ ă™ă‚‹ăčăă‹ïŒŸ + +æ–°ă—ă„APIă‚’äœœă‚‹ć Žćˆă€[APIをKubernetesă‚Żăƒ©ă‚čă‚żăƒŒAPIにスグăƒȘă‚ČăƒŒăƒˆ(集箄)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをă‚čă‚żăƒłăƒ‰ă‚ąăƒ­ăƒŒăƒłă§ć‹•ă‹ă™ă‹ă‚’æ€œèšŽă—ăŸă™ă€‚ + +| APIケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłă‚’äœżă†ć Žćˆ: | ă‚čă‚żăƒłăƒ‰ă‚ąăƒ­ăƒŒăƒłAPIă‚’äœżă†ć Žćˆ: | +| ------------------------------ | ---------------------------- | +| APIが[ćźŁèš€çš„](#ćźŁèš€çš„API) | APIが[ćźŁèš€çš„](#ćźŁèš€çš„API)ăƒąăƒ‡ăƒ«ă«é©ă•ăȘい | +| æ–°ă—ă„ăƒȘă‚œăƒŒă‚čを`kubectl`ă‚’äœżă„èȘ­ăżèŸŒăżă€æ›žăèŸŒăżă—ăŸă„| `kubectl`ăźă‚”ăƒăƒŒăƒˆăŻćż…èŠăȘい | +| æ–°ă—ă„ăƒȘă‚œăƒŒă‚čă‚’ăƒ€ăƒƒă‚·ăƒ„ăƒœăƒŒăƒ‰ăźă‚ˆă†ăȘ、Kubernetes UIă§ä»–ăźăƒ“ăƒ«ăƒˆă‚€ăƒłăƒȘă‚œăƒŒă‚čăšćŒă˜ă‚ˆă†ă«çźĄç†ă—ăŸă„ | Kubernetes UIăźă‚”ăƒăƒŒăƒˆăŻćż…èŠăȘい | +| æ–°ă—ă„APIを開ç™șしどいる | APIă‚’æäŸ›ă—ă€é©ćˆ‡ă«æ©Ÿèƒœă™ă‚‹ăƒ—ăƒ­ă‚°ăƒ©ăƒ ăŒæ—ąă«ć­˜ćœšă—ăŠă„ă‚‹ | +| APIă‚°ăƒ«ăƒŒăƒ—ă€ćć‰ç©ș間べいうようăȘ、RESTăƒȘă‚œăƒŒă‚čパă‚čにć‰Čă‚Šćœ“ăŠă‚‰ă‚ŒăŸă€Kubernetesăźăƒ•ă‚©ăƒŒăƒžăƒƒăƒˆä»•æ§˜ăźćˆ¶é™ă‚’èš±ćźčできる([API抂芁](/ja/docs/concepts/overview/kubernetes-api/)を揂照) | æ—ąă«ćźšçŸ©æžˆăżăźREST APIずäș’æ›æ€§ă‚’æŒăŁăŠă„ăȘければăȘらăȘい | +| ăƒȘă‚œăƒŒă‚čăŻă‚Żăƒ©ă‚čă‚żăƒŒă”ăšă‹ă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźćć‰ç©ș間にè‡Șç„¶ă«ćˆ†ă‘ă‚‹ă“ăšăŒă§ăă‚‹ | ă‚Żăƒ©ă‚čă‚żăƒŒă€ăŸăŸăŻćć‰ç©șé–“ă«ă‚ˆă‚‹ćˆ†ć‰ČがăƒȘă‚œăƒŒă‚č知理に適さăȘい。ç‰č漚ぼăƒȘă‚œăƒŒă‚čパă‚čにćŸșă„ă„ăŠçźĄç†ă—ăŸă„ | +| [Kubernetes APIă‚”ăƒăƒŒăƒˆæ©Ÿèƒœ](#äž€èˆŹçš„ăȘ機胜)ă‚’ć†ćˆ©ç”šă—ăŸă„ | ă“ă‚Œă‚‰ăźæ©ŸèƒœăŻćż…èŠăȘい | + +### ćźŁèš€çš„API + +ćźŁèš€çš„APIăŻă€é€šćžžă€äž‹èš˜ă«è©Čćœ“ă—ăŸă™: + + - APIăŻă€æŻ”èŒƒçš„ć°‘æ•°ăźă€æŻ”èŒƒçš„ć°ă•ăȘă‚Șブゾェクト(ăƒȘă‚œăƒŒă‚č)ă§æ§‹æˆă•ă‚ŒăŠă„ă‚‹ + - ă‚Șブゾェクトは、ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźèš­ćźšă€ă‚€ăƒłăƒ•ăƒ©ă‚čăƒˆăƒ©ă‚ŻăƒăƒŁăƒŒă‚’ćźšçŸ©ă™ă‚‹ + - ă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŻă€æŻ”èŒƒçš„æ›Žæ–°é »ćșŠăŒäœŽă„ + - äșșは、ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźæƒ…ć ±ă‚’ă‚ˆăèȘ­ăżæ›žăă™ă‚‹ + - ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ćŻŸă™ă‚‹äž»èŠăȘæ‰‹ç¶šăăŻă€CRUD(äœœæˆă€èȘ­ăżèŸŒăżă€æ›Žæ–°ă€ć‰Šé™€)にăȘる + - 耇数ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’ăŸăŸă„ă ăƒˆăƒ©ăƒłă‚¶ă‚Żă‚·ăƒ§ăƒłăŻćż…èŠăȘい: APIăŻä»ŠçŸćœšăźçŠ¶æ…‹ă§ăŻăȘく、あるăčăçŠ¶æ…‹ă‚’èĄšçŸă™ă‚‹ + +ć‘œä»€çš„APIăŻă€ćźŁèš€çš„ă§ăŻă‚ă‚ŠăŸă›ă‚“ă€‚ +APIăŒćźŁèš€çš„ă§ăŻăȘă„ć…†ć€™ăšă—ăŠă€æŹĄăźă‚‚ăźăŒă‚ă‚ŠăŸă™: + + - ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‹ă‚‰"ă“ă‚Œă‚’ćźŸèĄŒ"ăšć‘œä»€ăŒăăŠă€ćźŒäș†ăźèż”ç­”ă‚’ćŒæœŸçš„ă«ć—ă‘ć–ă‚‹ + - ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‹ă‚‰"ă“ă‚Œă‚’ćźŸèĄŒ"ăšć‘œä»€ăŒăăŠă€ć‡Šç†IDă‚’ć–ćŸ—ă™ă‚‹ă€‚ăă—ăŠć‡Šç†ăŒćźŒäș†ă—ăŸă‹ă©ă†ă‹ă‚’ă€ć‡Šç†IDă‚’ćˆ©ç”šă—ăŠćˆ„é€”ć•ă„ćˆă‚ă›ă‚‹ + - ăƒȘăƒąăƒŒăƒˆăƒ—ăƒ­ă‚·ăƒŒă‚žăƒŁă‚łăƒŒăƒ«(RPC)ăšă„ă†èš€è‘‰ăŒéŁ›ăłäș€ăŁăŠă„ă‚‹ + - ç›ŽæŽ„ă€ć€§é‡ăźăƒ‡ăƒŒă‚żă‚’æ ŒçŽă—ăŠă„ă‚‹(äŸ‹ă€1ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚ăŸă‚Šæ•°kBă‚ˆă‚Šć€§ăă„ă€ăŸăŸăŻæ•°ćƒă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚ˆă‚Šć€šă„) + - é«˜ćžŻćŸŸă‚ąă‚Żă‚»ă‚č(æŒç¶šçš„ă«æŻŽç§’æ•°ćăƒȘクスă‚čト)ăŒćż…èŠ + - ă‚šăƒłăƒ‰ăƒŠăƒŒă‚¶ăƒŒăźăƒ‡ăƒŒă‚ż(ç”»ćƒă€PIIă€ăăźä»–)ă‚’æ ŒçŽă—ăŠă„ă‚‹ă€ăŸăŸăŻă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăŒć‡Šç†ă™ă‚‹ć€§é‡ăźăƒ‡ăƒŒă‚żă‚’æ ŒçŽă—ăŠă„ă‚‹ + - ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ćŻŸă™ă‚‹ć‡Šç†ăŒă€CRUDではăȘい + - APIをă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăšă—ăŠç°Ąć˜ă«èĄšçŸă§ăăȘい + - ćœæ­ąă—ăŠă„ă‚‹ć‡Šç†ă‚’ć‡Šç†ID、もしくは懩理ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă§èĄšçŸă™ă‚‹ă“ăšă‚’éžæŠžă—ăŠă„ă‚‹ + +## ConfigMapずカă‚čタムăƒȘă‚œăƒŒă‚čăźă©ăĄă‚‰ă‚’äœżă†ăčきか? + +äž‹èš˜ăźă„ăšă‚Œă‹ă«è©Čćœ“ă™ă‚‹ć ŽćˆăŻă€ConfigMapă‚’äœżăŁăŠăă ă•ă„: + +* `mysql.cnf`、`pom.xml`ぼようăȘă€ććˆ†ă«æ–‡æ›žćŒ–ă•ă‚ŒăŸèš­ćźšăƒ•ă‚Ąă‚€ăƒ«ăƒ•ă‚©ăƒŒăƒžăƒƒăƒˆăŒæ—ąă«ć­˜ćœšă—ăŠă„ă‚‹ +* ć˜äž€ă‚­ăƒŒăźConfigMapă«ă€èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ăźć†…ćźčăźć…šăŠă‚’æ ŒçŽă—ăŠă„ă‚‹ +* èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ăźäž»ăȘç”šé€”ăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒäžŠăźPodă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ăƒ—ăƒ­ă‚°ăƒ©ăƒ ăŒăƒ•ă‚Ąă‚€ăƒ«ă‚’èȘ­ăżèŸŒăżă€ăă‚Œè‡Șäœ“ă‚’æ§‹æˆă™ă‚‹ă“ăšă§ă‚ă‚‹ +* ăƒ•ă‚Ąă‚€ăƒ«ăźćˆ©ç”šè€…ăŻă€Kubernetes APIよりも、Podć†…ăźăƒ•ă‚Ąă‚€ăƒ«ăŸăŸăŻPodć†…ăźç’°ćąƒć€‰æ•°ă‚’ä»‹ă—ăŠćˆ©ç”šă™ă‚‹ă“ăšă‚’ć„œă‚€ +* ăƒ•ă‚Ąă‚€ăƒ«ăŒæ›Žæ–°ă•ă‚ŒăŸăšăă«ă€DeploymentăȘă©ă‚’ä»‹ă—ăŠăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆă‚’èĄŒă„ăŸă„ + +{{< note >}} +ă‚»ăƒłă‚·ăƒ†ă‚Łăƒ–ăȘăƒ‡ăƒŒă‚żă«ăŻă€ConfigMapă«éĄžäŒŒă—ăŠă„ăŸă™ăŒă‚ˆă‚Šă‚»ă‚­ăƒ„ă‚ąăȘ[secret](/docs/concepts/configuration/secret/)ă‚’äœżăŁăŠăă ă•ă„ +{{< /note >}} + +äž‹èš˜ăźă»ăšă‚“ă©ă«è©Čćœ“ă™ă‚‹ć Žćˆă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚č(CRDă€ăŸăŸăŻă‚ąă‚°ăƒȘă‚ČăƒŒăƒˆAPI)ă‚’äœżăŁăŠăă ă•ă„: + +* æ–°ă—ă„ăƒȘă‚œăƒŒă‚čă‚’äœœæˆă€æ›Žæ–°ă™ă‚‹ăŸă‚ă«ă€Kubernetesăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒă€CLIă‚’äœżă„ăŸă„ +* kubectlăźăƒˆăƒƒăƒ—ăƒŹăƒ™ăƒ«ă‚”ăƒăƒŒăƒˆăŒæŹČしい(äŸ‹ă€`kubectl get my-object object-name`) +* æ–°ă—ă„è‡Șć‹•ćŒ–ăźä»•ç”„ăżă‚’äœœă‚Šă€æ–°ă—ă„ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźæ›Žæ–°ă‚’ă‚Šă‚©ăƒƒăƒă—ăŸă„ă€ăăźæ›Žæ–°ă‚’ć„‘æ©Ÿă«ä»–ăźă‚ȘブゾェクトぼCRUDă‚’ćźŸèĄŒă—ăŸă„ă€ăŸăŸăŻăăźé€†ă‚’èĄŒă„ăŸă„ +* ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźæ›Žæ–°ă‚’ć–ă‚Šæ‰±ă†ă€è‡Șć‹•ćŒ–ăźä»•ç”„ăżă‚’æ›žăăŸă„ +* `.spec`、`.status`、`.metadata`べいうようăȘ、Kubernetes APIăźæ…Łçż’ă‚’äœżă„ăŸă„ +* ă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŻă€ćˆ¶ćŸĄă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čă‚łăƒŹă‚Żă‚·ăƒ§ăƒłăźæŠœè±ĄćŒ–ă€ăŸăŸăŻä»–ăźăƒȘă‚œăƒŒă‚čăźă‚”ăƒžăƒȘăƒŒăšă—ăŸă„ + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’èżœćŠ ă™ă‚‹ + +KubernetesăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒăžă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’èżœćŠ ă™ă‚‹2぀たæ–čæł•ă‚’æäŸ›ă—ăŠă„ăŸă™: + +- CRDăŻă‚·ăƒłăƒ—ăƒ«ă§ă€ăƒ—ăƒ­ă‚°ăƒ©ăƒŸăƒłă‚°ăȘă—ă«äœœæˆćŻèƒœ +- [APIケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒł](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)ăŻă€ăƒ—ăƒ­ă‚°ăƒ©ăƒŸăƒłă‚°ăŒćż…èŠă ăŒă€ăƒ‡ăƒŒă‚żăŒă©ăźă‚ˆă†ă«æ ŒçŽă•ă‚Œă€APIăƒăƒŒă‚žăƒ§ăƒłé–“ă§ă©ăźă‚ˆă†ă«ć€‰æ›ă•ă‚Œă‚‹ă‹ăšă„ă†ă‚ˆă†ăȘă€ă‚ˆă‚Šè©łçŽ°ăȘAPIăźæŒŻă‚‹èˆžă„ă‚’ćˆ¶ćŸĄă§ăă‚‹ + +KubernetesăŻă€ă•ăŸă–ăŸăȘăƒŠăƒŒă‚¶ăƒŒăźăƒ‹ăƒŒă‚șをæș€ăŸă™ăŸă‚ă«ă“ă‚Œă‚‰2぀たă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’æäŸ›ă—ăŠăŠă‚Šă€äœżă„ă‚„ă™ă•ă‚„æŸ”è»Ÿæ€§ăŒæăȘă‚ă‚Œă‚‹ă“ăšăŻă‚ă‚ŠăŸă›ă‚“ă€‚ + +ケグăƒȘă‚ČăƒŒăƒˆAPIăŻă€ăƒ—ăƒ­ă‚­ă‚·ăƒŒăšă—ăŠæ©Ÿèƒœă™ă‚‹ăƒ—ăƒ©ă‚€ăƒžăƒȘAPIă‚”ăƒŒăƒăƒŒăźèƒŒćŸŒă«ă‚ă‚‹ă€äž‹äœăźAPIServerです。こぼようăȘé…çœźăŻ[APIケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒł](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)ăšć‘Œă°ă‚ŒăŠă„ăŸă™ă€‚ăƒŠăƒŒă‚¶ăƒŒă«ăšăŁăŠăŻă€ć˜ă«APIă‚”ăƒŒăƒăƒŒăŒæ‹ĄćŒ”ă•ă‚ŒăŠă„ă‚‹ă‚ˆă†ă«èŠ‹ăˆăŸă™ă€‚ + +CRDでは、APIă‚”ăƒŒăƒăƒŒăźèżœćŠ ăȘă—ă«ă€ăƒŠăƒŒă‚¶ăƒŒăŒæ–°ă—ă„çšźéĄžăźăƒȘă‚œăƒŒă‚čă‚’äœœæˆă§ăăŸă™ă€‚CRDă‚’äœżă†ă«ăŻă€APIケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłă‚’ç†è§Łă™ă‚‹ćż…èŠăŻă‚ă‚ŠăŸă›ă‚“ă€‚ + +ă©ăźă‚ˆă†ă«ă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă•ă‚ŒăŸă‹ă«é–ąă‚ă‚‰ăšă€æ–°ă—ă„ăƒȘă‚œăƒŒă‚čはカă‚čタムăƒȘă‚œăƒŒă‚čăšă—ăŠć‚ç…§ă•ă‚Œă€ăƒ“ăƒ«ăƒˆă‚€ăƒłăźKubernetesăƒȘă‚œăƒŒă‚č(PodăȘど)ずはćŒșćˆ„ă•ă‚ŒăŸă™ă€‚ + +## CustomResourceDefinition + +[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIăƒȘă‚œăƒŒă‚čは、カă‚čタムăƒȘă‚œăƒŒă‚čă‚’ćźšçŸ©ă—ăŸă™ă€‚CRDă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’ćźšçŸ©ă™ă‚‹ă“ăšă§ă€æŒ‡ćźšă—ăŸćć‰ă€ă‚čă‚­ăƒŒăƒžă§æ–°ă—ă„ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăŒäœœæˆă•ă‚ŒăŸă™ă€‚Kubernetes APIăŻă€äœœæˆă—ăŸă‚«ă‚čタムăƒȘă‚œăƒŒă‚čたă‚čăƒˆăƒŹăƒŒă‚žă‚’æäŸ›ă€ăŠă‚ˆăłć‡Šç†ă—ăŸă™ă€‚ + +ă“ă‚ŒăŻă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’ć‡Šç†ă™ă‚‹ăŸă‚ă«ă€ç‹Źè‡ȘたAPIă‚”ăƒŒăƒăƒŒă‚’æ›žăă“ăšă‹ă‚‰è§Łæ”Ÿă—ăŠăă‚ŒăŸă™ăŒă€äž€èˆŹçš„ăȘ性èłȘべしど[APIă‚”ăƒŒăƒăƒŒă‚ąă‚°ăƒȘă‚ČăƒŒă‚·ăƒ§ăƒł](#APIă‚”ăƒŒăƒăƒŒă‚ąă‚°ăƒȘă‚ČăƒŒă‚·ăƒ§ăƒł)ăšæŻ”ăčă‚‹ăšă€æŸ”è»Ÿæ€§ă«æŹ ă‘ăŸă™ă€‚ + +æ–°ă—ă„ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’ă©ăźă‚ˆă†ă«ç™»éŒČă™ă‚‹ă‹ă€æ–°ă—ă„ăƒȘă‚œăƒŒă‚čă‚żă‚€ăƒ—ăšăźé€Łæșă€ăă—ăŠă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’äœżă„ă‚€ăƒ™ăƒłăƒˆă‚’ć‡Šç†ă™ă‚‹æ–čæł•äŸ‹ă«ă€ă„ăŠă€[ă‚«ă‚čă‚żăƒ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒäŸ‹](https://github.com/kubernetes/sample-controller)を揂照しどください。 + +## APIă‚”ăƒŒăƒăƒŒă‚ąă‚°ăƒȘă‚ČăƒŒă‚·ăƒ§ăƒł + +通澾、Kubernetes APIぼ搄ăƒȘă‚œăƒŒă‚čは、RESTăƒȘクスă‚čトずă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźæ°žç¶šçš„ăȘă‚čăƒˆăƒŹăƒŒă‚žă‚’çźĄç†ă™ă‚‹ăŸă‚ăźă‚łăƒŒăƒ‰ăŒćż…èŠă§ă™ă€‚ăƒĄă‚€ăƒłăźKubernetes APIă‚”ăƒŒăƒăƒŒăŻ *Pod* や *Service* ぼようăȘăƒ“ăƒ«ăƒˆă‚€ăƒłăźăƒȘă‚œăƒŒă‚čă‚’ć‡Šç†ă—ă€ăŸăŸ[CRD](#customresourcedefinition)を通じど、搌じæ–čæł•ă§ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚‚çźĄç†ă§ăăŸă™ă€‚ + +[ケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłăƒŹă‚€ăƒ€ăƒŒ](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独è‡Șたă‚čă‚żăƒłăƒ‰ă‚ąăƒ­ăƒŒăƒłAPIă‚”ăƒŒăƒăƒŒă‚’æ›žăă€ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹ă“ăšă§ă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čにç‰čćŒ–ă—ăŸćźŸèŁ…ăźæäŸ›ă‚’ćŻèƒœă«ă—ăŸă™ă€‚ăƒĄă‚€ăƒłăźAPIă‚”ăƒŒăƒăƒŒăŒă€ć‡Šç†ă—ăŸă„ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čぞたăƒȘクスă‚čトを槔è­Čă™ă‚‹ă“ăšă§ă€ä»–ăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‹ă‚‰ă‚‚ćˆ©ç”šă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăźèżœćŠ æ–čæł•ă‚’éžæŠžă™ă‚‹ + +CRDăŻç°Ąć˜ă«äœżăˆăŸă™ă€‚ă‚ąă‚°ăƒȘă‚ČăƒŒăƒˆAPIăŻă‚ˆă‚ŠæŸ”è»Ÿă§ă™ă€‚ăƒ‹ăƒŒă‚șă«æœ€ă‚‚ćˆă†æ–čæł•ă‚’éžæŠžă—ăŠăă ă•ă„ă€‚ + +通澾、CRDăŻäž‹èš˜ăźć Žćˆă«é©ă—ăŠă„ăŸă™: + +* ć°‘æ•°ăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă—ă‹ćż…èŠăȘい +* そぼăƒȘă‚œăƒŒă‚čăŻç€Ÿć†…ăźăżă§ćˆ©ç”šă—ăŠă„ă‚‹ă€ăŸăŸăŻć°ă•ă„ă‚ȘăƒŒăƒ—ăƒłă‚œăƒŒă‚čăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆăźäž€éƒšă§ćˆ©ç”šă—ăŠă„ă‚‹(敆甹プロダクトではăȘい) + +### äœżă„ă‚„ă™ă•ăźæŻ”èŒƒ + +CRDは、ケグăƒȘă‚ČăƒŒăƒˆAPIăšæŻ”ăčă€ç°Ąć˜ă«äœœă‚ŒăŸă™ă€‚ + +| CRD | ケグăƒȘă‚ČăƒŒăƒˆAPI | +| -------------------------- | --------------- | +| ăƒ—ăƒ­ă‚°ăƒ©ăƒŸăƒłă‚°ăŒäžèŠă§ă€ăƒŠăƒŒă‚¶ăƒŒăŻCRDă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšă—ăŠă©ăźèš€èȘžă§ă‚‚éžæŠžćŻèƒœ | Go蚀èȘžă§ăƒ—ăƒ­ă‚°ăƒ©ăƒŸăƒłă‚°ă—ă€ăƒă‚€ăƒŠăƒȘăšă‚€ăƒĄăƒŒă‚žăźäœœæˆăŒćż…èŠă€‚ăƒŠăƒŒă‚¶ăƒŒăŻCRDă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšă—ăŠă©ăźèš€èȘžă§ă‚‚éžæŠžćŻèƒœ | +| èżœćŠ ăźă‚”ăƒŒăƒ“ă‚čăŻäžèŠă€‚ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čはAPIă‚”ăƒŒăƒăƒŒă§ć‡Šç†ă•ă‚Œă‚‹ | èżœćŠ ăźă‚”ăƒŒăƒ“ă‚čäœœæˆăŒćż…èŠă§ă€éšœćźłăŒç™șç”Ÿă™ă‚‹ćŻèƒœæ€§ăŒă‚ă‚‹ | +| CRDăŒäœœæˆă•ă‚Œă‚‹ăšă€ç¶™ç¶šçš„ăȘă‚”ăƒăƒŒăƒˆăŻç„Ąă„ă€‚ăƒă‚°äżźæ­ŁăŻé€šćžžăźKubernetesマă‚čă‚żăƒŒăźă‚ąăƒƒăƒ—ă‚°ăƒŹăƒŒăƒ‰ă§èĄŒă‚ă‚Œă‚‹ | ćźšæœŸçš„ă«ă‚ąăƒƒăƒ—ă‚čトăƒȘăƒŒăƒ ă‹ă‚‰ăƒă‚°äżźæ­Łăźć–ă‚ŠèŸŒăżă€ăƒȘăƒ“ăƒ«ăƒ‰ă€ăă—ăŠă‚ąă‚°ăƒȘă‚ČăƒŒăƒˆAPIă‚”ăƒŒăƒăƒŒăźæ›Žæ–°ăŒćż…èŠă‹ă‚‚ă—ă‚ŒăȘい | +| è€‡æ•°ăƒăƒŒă‚žăƒ§ăƒłăźAPIçźĄç†ăŻäžèŠă€‚äŸ‹ăˆă°ă€ă‚ă‚‹ăƒȘă‚œăƒŒă‚čă‚’æ“äœœă™ă‚‹ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‚’çźĄç†ă—ăŠă„ăŸć Žćˆă€APIăźă‚ąăƒƒăƒ—ă‚°ăƒŹăƒŒăƒ‰ăšäž€ç·’ă«æ›Žæ–°ă•ă‚Œă‚‹ | è€‡æ•°ăƒăƒŒă‚žăƒ§ăƒłăźAPIを缡理しăȘければăȘらăȘă„ă€‚äŸ‹ăˆă°ă€äž–ç•Œäž­ă«ć…±æœ‰ă•ă‚ŒăŠă„ă‚‹æ‹ĄćŒ”æ©Ÿèƒœă‚’é–‹ç™șしどいる栮搈 | + +### 高ćșŠăȘæ©Ÿèƒœă€æŸ”è»Ÿæ€§ + +ケグăƒȘă‚ČăƒŒăƒˆAPIăŻă€äŸ‹ăˆă°ă‚čăƒˆăƒŹăƒŒă‚žăƒŹă‚€ăƒ€ăƒŒăźă‚«ă‚čă‚żăƒžă‚€ă‚șぼようăȘă€ă‚ˆă‚Šé«˜ćșŠăȘAPIæ©Ÿèƒœăšä»–ăźæ©Ÿèƒœăźă‚«ă‚čă‚żăƒžă‚€ă‚șă‚’ćŻèƒœă«ă—ăŸă™ă€‚ + +| 機胜 | è©łçŽ° | CRD | ケグăƒȘă‚ČăƒŒăƒˆAPI | +| ---- | ---- | --- | --------------- | +| バăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒł | ă‚šăƒ©ăƒŒă‚’äșˆé˜Čă—ă€ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăšç„Ąé–ąäż‚ă«APIをç™șé”ă•ă›ă‚‹ă“ăšăŒă§ăă‚‹ă‚ˆă†ă«ăȘă‚‹ă€‚ă“ă‚Œă‚‰ăźæ©ŸèƒœăŻć€šæ•°ăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăŒăŠă‚Šă€ćŒæ™‚ă«ć…šăŠă‚’æ›Žæ–°ă§ăăȘă„ăšăă«æœ€ă‚‚ćŠčæžœă‚’ç™șæźă™ă‚‹ | ăŻă„ă€ă»ăšă‚“ă©ăźăƒăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłăŻ[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDă«æŒ‡ćźšă§ăă‚‹ă€‚ăăźä»–ăźăƒăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłăŻ[WebhookたバăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒł](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)ă«ă‚ˆă‚Šă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ă‚‹ | ăŻă„ă€ä»»æ„ăźăƒăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłăŒćŻèƒœ | +| ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆèš­ćźš | äžŠèš˜ă‚’ć‚ç…§ | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)た`default`ă‚­ăƒŒăƒŻăƒŒăƒ‰(1.16ă§ăƒ™ăƒŒă‚ż)ă€ăŸăŸăŻ[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)ă‚’é€šă˜ăŠćŻèƒœ | はい | +| è€‡æ•°ăƒăƒŒă‚žăƒ§ăƒ‹ăƒłă‚° | 搌じă‚Șブゾェクトを、違うAPIăƒăƒŒă‚žăƒ§ăƒłă§ćˆ©ç”šćŻèƒœă«ă™ă‚‹ă€‚ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźćć‰ă‚’ć€‰æ›Žă™ă‚‹ăȘどたAPIăźć€‰æ›Žă‚’ç°Ąć˜ă«èĄŒă†ăźă«ćœčç«‹ă€ă€‚ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăźăƒăƒŒă‚žăƒ§ăƒłă‚’çźĄç†ă™ă‚‹ć Žćˆă€é‡èŠæ€§ăŻäž‹ăŒă‚‹ | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | +| ă‚«ă‚čタムă‚čăƒˆăƒŹăƒŒă‚ž | 異ăȘă‚‹æ€§èƒœăźă‚čăƒˆăƒŹăƒŒă‚žăŒćż…èŠăȘ栎搈(äŸ‹ăˆă°ă€ă‚­ăƒŒăƒăƒȘăƒ„ăƒŒă‚čăƒˆă‚ąăźä»Łă‚ă‚Šă«æ™‚çł»ćˆ—ăƒ‡ăƒŒă‚żăƒ™ăƒŒă‚č)ăŸăŸăŻă€ă‚»ă‚­ăƒ„ăƒȘティぼ戆雱(äŸ‹ăˆă°ă€æ©ŸćŻ†æƒ…ć ±ăźæš—ć·ćŒ–ă€ăăźä»–)| いいえ | はい | +| ă‚«ă‚čタムビゾネă‚čロゾック | ă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŒäœœæˆă€èȘ­ăżèŸŒăżă€æ›Žæ–°ă€ăŸăŸć‰Šé™€ă•ă‚Œă‚‹ăšăă«ä»»æ„ăźăƒă‚§ăƒƒă‚Żă€ă‚ąă‚Żă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă™ă‚‹| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)ă‚’ćˆ©ç”š | はい | +| ă‚”ăƒ–ăƒȘă‚œăƒŒă‚čたă‚čă‚±ăƒŒăƒ« | HorizontalPodAutoscalerやPodDisruptionBudgetăȘどたシă‚čăƒ†ăƒ ăŒă€æ–°ă—ă„ăƒȘă‚œăƒŒă‚čべ連æșă§ăă‚‹ă‚ˆă†ă«ă™ă‚‹ | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | +| ă‚”ăƒ–ăƒȘă‚œăƒŒă‚čăźçŠ¶æ…‹ |
  • ă‚ˆă‚Šè©łçŽ°ăȘă‚ąă‚Żă‚»ă‚čă‚łăƒłăƒˆăƒ­ăƒŒăƒ«: ăƒŠăƒŒă‚¶ăƒŒăŒspecă‚»ă‚Żă‚·ăƒ§ăƒłă«æ›žăèŸŒăżă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒstatusă‚»ă‚Żă‚·ăƒ§ăƒłă«æ›žăèŸŒă‚€
  • ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăźăƒ‡ăƒŒă‚żć€‰æ›æ™‚ă«ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăźäž–ä»Łă‚’äžŠă’ă‚‰ă‚Œă‚‹ă‚ˆă†ă«ă™ă‚‹(ăƒȘă‚œăƒŒă‚čがspecべ、statusă§ă‚»ă‚Żă‚·ăƒ§ăƒłăŒćˆ†é›ąă—ăŠă„ă‚‹ćż…èŠăŒă‚ă‚‹)
| [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| ăăźä»–ăźă‚”ăƒ–ăƒȘă‚œăƒŒă‚č | "logs"や"exec"ぼようăȘ、CRUDä»„ć€–ăźć‡Šç†ăźèżœćŠ  | いいえ | はい | +| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHă‚’ă‚”ăƒăƒŒăƒˆă™ă‚‹æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă€‚ăƒ­ăƒŒă‚«ăƒ«ă€ă‚”ăƒŒăƒăƒŒă€ă©ăĄă‚‰ă§ă‚‚æ›Žæ–°ă•ă‚Œă†ă‚‹ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«æœ‰ç”šă€‚ă•ă‚‰ăȘă‚‹æƒ…ć ±ăŻ["APIă‚Șブゾェクトをkubectl patchでæ±șăŸăŁăŸć Žæ‰€ă§æ›Žæ–°"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を揂照 | いいえ | はい | +| ăƒ—ăƒ­ăƒˆă‚łăƒ«ăƒăƒƒăƒ•ă‚Ą | ăƒ—ăƒ­ăƒˆă‚łăƒ«ăƒăƒƒăƒ•ă‚Ąă‚’äœżç”šă™ă‚‹ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‚’ă‚”ăƒăƒŒăƒˆă™ă‚‹æ–°ă—ă„ăƒȘă‚œăƒŒă‚č | いいえ | はい | +| OpenAPIă‚čă‚­ăƒŒăƒž | ă‚”ăƒŒăƒăƒŒă‹ă‚‰ć‹•çš„ă«ć–ćŸ—ă§ăă‚‹ćž‹ăźOpenAPI(ă‚čăƒŻăƒƒă‚ŹăƒŒ)ă‚čă‚­ăƒŒăƒžăŻă‚ă‚‹ă‹ă€èš±ćŻă•ă‚ŒăŸăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźăżăŒèš­ćźšă•ă‚Œă‚‹ă‚ˆă†ă«ă™ă‚‹ă“ăšă§ă€ăƒŠăƒŒă‚¶ăƒŒăŻăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ćăźă‚čăƒšăƒ«ăƒŸă‚čă‹ă‚‰äżè­·ă•ă‚ŒăŠă„ă‚‹ă‹ă€ćž‹ăŻćŒ·ćˆ¶ă•ă‚ŒăŠă„ă‚‹ă‹(èš€ă„æ›ăˆă‚‹ăšă€ă€Œæ–‡ć­—ćˆ—ă€ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă«ă€Œintă€ă‚’ć…„ă‚Œă•ă›ăȘい) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) ă‚čă‚­ăƒŒăƒžăŒăƒ™ăƒŒă‚č(1.16でGA) | はい | + +### äž€èˆŹçš„ăȘ機胜 + +CRDă€ăŸăŸăŻă‚ąă‚°ăƒȘă‚ČăƒŒăƒˆAPIă€ă©ăĄă‚‰ă‚’äœżăŁăŠă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’äœœăŁăŸć Žćˆă§ă‚‚ă€Kubernetesăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ć€–ă§APIă‚’ćźŸèŁ…ă™ă‚‹ăźă«æŻ”ăčă€ć€šæ•°ăźæ©ŸèƒœăŒæäŸ›ă•ă‚ŒăŸă™: + +| 機胜 | äœ•ă‚’ćźŸçŸă™ă‚‹ă‹ | +| ---- | -------------- | +| CRUD | æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒă€HTTP、`kubectl`を通じど、ćŸșæœŹçš„ăȘCRUDć‡Šç†ă‚’ă‚”ăƒăƒŒăƒˆ | +| Watch | æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒă€HTTPを通じど、KubernetesたWatchć‡Šç†ă‚’ă‚”ăƒăƒŒăƒˆ | +| Discovery | kubectlă‚„ăƒ€ăƒƒă‚·ăƒ„ăƒœăƒŒăƒ‰ăźă‚ˆă†ăȘă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăŒă€è‡Ș拕的にăƒȘă‚œăƒŒă‚čăźäž€èŠ§èĄšç€șă€ć€‹ćˆ„èĄšç€șă€ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźç·šé›†ć‡Šç†ă‚’æäŸ› | +| json-patch | æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒ`Content-Type: application/json-patch+json`を甹いたPATCHă‚’ă‚”ăƒăƒŒăƒˆ | +| merge-patch | æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒ`Content-Type: application/merge-patch+json`を甹いたPATCHă‚’ă‚”ăƒăƒŒăƒˆ | +| HTTPS | æ–°ă—ă„ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒHTTPSă‚’ćˆ©ç”š | +| ăƒ“ăƒ«ăƒˆă‚€ăƒłèȘèšŒ | æ‹ĄćŒ”æ©Ÿèƒœăžăźă‚ąă‚Żă‚»ă‚čにèȘèšŒăźăŸă‚ă€ă‚łă‚ąAPIă‚”ăƒŒăƒăƒŒ(ケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłăƒŹă‚€ăƒ€ăƒŒ)ă‚’ćˆ©ç”š | +| ăƒ“ăƒ«ăƒˆă‚€ăƒłèȘćŻ | æ‹ĄćŒ”æ©Ÿèƒœăžăźă‚ąă‚Żă‚»ă‚čにコスAPIă‚”ăƒŒăƒăƒŒă§äœżă‚ă‚ŒăŠă„ă‚‹èȘćŻæ©Ÿæ§‹ă‚’ć†ćˆ©ç”š(äŸ‹ă€RBAC) | +| ăƒ•ă‚Ąă‚€ăƒŠăƒ©ă‚€ă‚¶ăƒŒ | ć€–éƒšăƒȘă‚œăƒŒă‚čăźć‰Šé™€ăŒç”‚ă‚ă‚‹ăŸă§ă€æ‹ĄćŒ”ăƒȘă‚œăƒŒă‚čăźć‰Šé™€ă‚’ăƒ–ăƒ­ăƒƒă‚Ż | +| Admission Webhooks | æ‹ĄćŒ”ăƒȘă‚œăƒŒă‚čăźäœœæˆ/曎新/ć‰Šé™€ć‡Šç†æ™‚ă«ă€ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ăźèš­ćźšă€ăƒăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłă‚’ćźŸæ–œ | +| UI/CLI èĄšç€ș | kubectlă€ăƒ€ăƒƒă‚·ăƒ„ăƒœăƒŒăƒ‰ă§æ‹ĄćŒ”ăƒȘă‚œăƒŒă‚čă‚’èĄšç€ș | +| æœȘèš­ćźš vs ç©șèš­ćźš | ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăŻă€ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźæœȘèš­ćźšăšă‚Œăƒ­ć€€ă‚’ćŒșćˆ„ă™ă‚‹ă“ăšăŒă§ăă‚‹ | +| ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒăźç”Ÿæˆ | KubernetesăŻă€äž€èˆŹçš„ăȘă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒăšă€ă‚żă‚€ăƒ—ć›șæœ‰ăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒă‚’ç”Ÿæˆă™ă‚‹ăƒ„ăƒŒăƒ«ă‚’æäŸ› | +| ăƒ©ăƒ™ăƒ«ăšă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒł | ăƒ„ăƒŒăƒ«ăŒă‚łă‚ąăƒȘă‚œăƒŒă‚čずカă‚čタムăƒȘă‚œăƒŒă‚čた線集æ–čæł•ă‚’çŸ„ăŁăŠă„ă‚‹ă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆé–“ă§ă€ć…±é€šăźăƒĄă‚żăƒ‡ăƒŒă‚żă‚’æäŸ› | + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăźă‚€ăƒłă‚čăƒˆăƒŒăƒ«æș–ć‚™ + +ă‚Żăƒ©ă‚čă‚żăƒŒă«ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’èżœćŠ ă™ă‚‹ć‰ă«ă€ă„ăă€ă‹èȘè­˜ă—どどくăčきäș‹é …ăŒă‚ă‚ŠăŸă™ă€‚ + +### ă‚”ăƒŒăƒ‰ăƒ‘ăƒŒăƒ†ă‚Łăźă‚łăƒŒăƒ‰ăšæ–°ă—ă„éšœćźłç‚č + +CRDă‚’äœœæˆă—ăŠă‚‚ă€ć‹æ‰‹ă«æ–°ă—ă„éšœćźłç‚čăŒèżœćŠ ă•ă‚ŒăŠă—ăŸă†ă“ăšăŻă‚ă‚ŠăŸă›ă‚“ăŒïŒˆăŸăšăˆă°ă€ă‚”ăƒŒăƒ‰ăƒ‘ăƒŒăƒ†ă‚Łăźă‚łăƒŒăƒ‰ă‚’APIă‚”ăƒŒăƒăƒŒă§ćźŸèĄŒă™ă‚‹ă“ăšă«ă‚ˆăŁăŠïŒ‰ă€ăƒ‘ăƒƒă‚±ăƒŒă‚žïŒˆăŸăšăˆă°ă€ăƒăƒŁăƒŒăƒˆïŒ‰ăŸăŸăŻăăźä»–ăźă‚€ăƒłă‚čăƒˆăƒŒăƒ«ăƒăƒłăƒ‰ăƒ«ă«ăŻă€ć€šăăźć Žćˆă€CRDăšæ–°ă—ă„ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čぼビゾネă‚čăƒ­ă‚žăƒƒă‚Żă‚’ćźŸèŁ…ă™ă‚‹ă‚”ăƒŒăƒ‰ăƒ‘ăƒŒăƒ†ă‚Łă‚łăƒŒăƒ‰ăŒć…„ăŁăŸDeploymentăŒć«ăŸă‚ŒăŸă™ă€‚ + +ケグăƒȘă‚ČăƒŒăƒˆAPIă‚”ăƒŒăƒăƒŒăźă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă™ă‚‹ăšă€ćžžă«æ–°ă—ă„DeploymentăŒä»˜ă„ăŠăăŸă™ă€‚ + +### ă‚čăƒˆăƒŹăƒŒă‚ž + +ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čは、ConfigMapべ搌じæ–čæł•ă§ă‚čăƒˆăƒŹăƒŒă‚žăźćźčé‡ă‚’æ¶ˆèČ»ă—ăŸă™ă€‚ć€šæ•°ăźă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’äœœæˆă™ă‚‹ăšă€APIă‚”ăƒŒăƒăƒŒăźă‚čăƒˆăƒŹăƒŒă‚žćźčé‡ă‚’è¶…ăˆăŠă—ăŸă†ă‹ă‚‚ă—ă‚ŒăŸă›ă‚“ă€‚ + +ケグăƒȘă‚ČăƒŒăƒˆAPIă‚”ăƒŒăƒăƒŒă‚‚ă€ăƒĄă‚€ăƒłăźAPIă‚”ăƒŒăƒăƒŒăšćŒă˜ă‚čăƒˆăƒŹăƒŒă‚žă‚’ćˆ©ç”šă™ă‚‹ă‹ă‚‚ă—ă‚ŒăŸă›ă‚“ă€‚ăăźć Žćˆă€ćŒă˜ć•éĄŒăŒç™șç”Ÿă—ăˆăŸă™ă€‚ + +### èȘèšŒă€èȘćŻă€ăă—ăŠç›ŁæŸ» + +CRDでは、APIă‚”ăƒŒăƒăƒŒăźăƒ“ăƒ«ăƒˆă‚€ăƒłăƒȘă‚œăƒŒă‚čべ搌じèȘèšŒă€èȘćŻă€ăă—ăŠç›ŁæŸ»ăƒ­ă‚źăƒłă‚°ăźä»•ç”„ăżă‚’ćˆ©ç”šă—ăŸă™ă€‚ + +もしRBACă‚’äœżăŁăŠă„ă‚‹ć Žćˆă€ă»ăšă‚“ă©ăźRBACăźăƒ­ăƒŒăƒ«ăŻæ–°ă—ă„ăƒȘă‚œăƒŒă‚čぞたスクセă‚čă‚’èš±ćŻă—ăŸă›ă‚“ă€‚(ă‚Żăƒ©ă‚čă‚żăƒŒçźĄç†è€…ăƒ­ăƒŒăƒ«ă€ă‚‚ă—ăăŻăƒŻă‚€ăƒ«ăƒ‰ă‚«ăƒŒăƒ‰ă§äœœæˆă•ă‚ŒăŸăƒ­ăƒŒăƒ«ă‚’é™€ă)æ–°ă—ă„ăƒȘă‚œăƒŒă‚čă«ăŻă€æ˜Žç€ș的にスクセă‚čă‚’èš±ćŻă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ć€šăăźć Žćˆă€CRDおよびケグăƒȘă‚ČăƒŒăƒˆAPIă«ăŻă€èżœćŠ ă™ă‚‹ă‚żă‚€ăƒ—ăźæ–°ă—ă„ăƒ­ăƒŒăƒ«ćźšçŸ©ăŒăƒăƒłăƒ‰ăƒ«ă•ă‚ŒăŠă„ăŸă™ă€‚ + +ケグăƒȘă‚ČăƒŒăƒˆAPIă‚”ăƒŒăƒăƒŒă§ăŻă€APIă‚”ăƒŒăƒăƒŒăźăƒ“ăƒ«ăƒˆă‚€ăƒłăƒȘă‚œăƒŒă‚čべ搌じèȘèšŒă€èȘćŻă€ăă—ăŠç›ŁæŸ»ăźä»•ç”„ăżă‚’äœżă†ć Žćˆăšäœżă‚ăȘă„ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ + +## ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čぞたスクセă‚č + +Kubernetesた[ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒ](/docs/reference/using-api/client-libraries/)ă‚’äœżă„ă€ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čにスクセă‚čă™ă‚‹ă“ăšăŒćŻèƒœă§ă™ă€‚ć…šăŠăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒăŒă‚«ă‚čタムăƒȘă‚œăƒŒă‚čă‚’ă‚”ăƒăƒŒăƒˆă—ăŠă„ă‚‹ă‚ă‘ă§ăŻç„Ąă„ă§ă™ăŒă€GoずPythonăźăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒăŻă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ + +ă‚«ă‚čタムăƒȘă‚œăƒŒă‚čăŻă€äž‹èš˜ăźă‚ˆă†ăȘæ–čæł•ă§æ“äœœă§ăăŸă™: + +- kubectl +- kubernetesăźć‹•çš„ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆ +- è‡ȘäœœăźRESTă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆ +- [Kubernetesă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆç”Ÿæˆăƒ„ăƒŒăƒ«](https://github.com/kubernetes/code-generator)ă‚’äœżă„ç”Ÿæˆă—ăŸă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆ(ç”ŸæˆăŻé«˜ćșŠăȘäœœæ„­ă§ă™ăŒă€äž€éƒšăźăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŻă€CRDăŸăŸăŻAAăšăšă‚‚ă«ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆă‚’æäŸ›ă™ă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™) + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Kubernetes APIをケグăƒȘă‚ČăƒŒă‚·ăƒ§ăƒłăƒŹă‚€ăƒ€ăƒŒă§æ‹ĄćŒ”ă™ă‚‹æ–čæł•](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)に぀いお歊ぶ +* [Kubernetes APIをCustomResourceDefinitionă§æ‹ĄćŒ”ă™ă‚‹æ–čæł•](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)に぀いお歊ぶ + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/_index.md b/content/ja/docs/concepts/overview/_index.md index 93a6320fa5..5bcc15f96b 100755 --- a/content/ja/docs/concepts/overview/_index.md +++ b/content/ja/docs/concepts/overview/_index.md @@ -1,5 +1,4 @@ --- -title: "Overview" +title: "抂芁" weight: 20 --- - diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 52f644b22f..3824bde0c6 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -8,7 +8,15 @@ card: --- {{% capture overview %}} +Kubernetesă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹ăšă€ă‚Żăƒ©ă‚čă‚żăƒŒăŒć±•é–‹ă•ă‚ŒăŸă™ă€‚ +{{< glossary_definition term_id="cluster" length="all" prepend="ă‚Żăƒ©ă‚čă‚żăƒŒăŻă€">}} + ă“ăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă§ăŻă€Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒăŒæ©Ÿèƒœă™ă‚‹ăŸă‚ă«ćż…èŠăšăȘă‚‹ă•ăŸă–ăŸăȘă‚łăƒłăƒăƒŒăƒăƒłăƒˆăźæŠ‚èŠă‚’èȘŹæ˜Žă—ăŸă™ă€‚ + +すăčăŠăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆăŒç”ăłä»˜ă‘ă‚‰ă‚ŒăŸKubernetesă‚Żăƒ©ă‚čă‚żăƒŒăźć›łă‚’æŹĄă«ç€șă—ăŸă™ă€‚ + +![Kubernetesăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆ](/images/docs/components-of-kubernetes.png) + {{% /capture %}} {{% capture body %}} @@ -106,7 +114,8 @@ Kubernetesă«ă‚ˆăŁăŠé–‹ć§‹ă•ă‚ŒăŸă‚łăƒłăƒ†ăƒŠăŻă€DNSæ€œçŽąă«ă“ăźDNSă‚” {{% /capture %}} {{% capture whatsnext %}} -* [ăƒŽăƒŒăƒ‰](/docs/concepts/architecture/nodes/) に぀いお歊ぶ -* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) に぀いお歊ぶ -* etcdăźć…ŹćŒ [ăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](https://etcd.io/docs/) をèȘ­ă‚€ +* [ăƒŽăƒŒăƒ‰](/ja/docs/concepts/architecture/nodes/)に぀いお歊ぶ +* [ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/architecture/controller/)に぀いお歊ぶ +* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)に぀いお歊ぶ +* etcdăźć…ŹćŒ [ăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](https://etcd.io/docs/)をèȘ­ă‚€ {{% /capture %}} diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 43fe3feb9d..01a41309de 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -67,7 +67,7 @@ APIăŒă€ă‚·ă‚čテムăƒȘă‚œăƒŒă‚čăšć‹•äœœă«ă€ă„ăŠæ˜Žçąșか぀䞀èČ«ă—ăŸ APIăšă‚œăƒ•ăƒˆă‚Šă‚šă‚ąăźăƒăƒŒă‚žăƒ§ăƒ‹ăƒłă‚°ăŻă€é–“æŽ„çš„ă«ă—ă‹é–ąé€Łă—ăŠă„ăȘă„ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚[APIずăƒȘăƒȘăƒŒă‚čăƒăƒŒă‚žăƒ§ăƒ‹ăƒłă‚°ææĄˆ](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIăšă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąăźăƒăƒŒă‚žăƒ§ăƒ‹ăƒłă‚°ăźé–ąé€Łă«ă€ă„ăŠèš˜èŒ‰ă—ăŠă„ăŸă™ă€‚ -異ăȘă‚‹ăƒăƒŒă‚žăƒ§ăƒłăźAPIは、異ăȘă‚‹ăƒŹăƒ™ăƒ«ïŒˆç‰ˆïŒ‰ăźćź‰ćźšæ€§ăšă‚”ăƒăƒŒăƒˆă‚’æŒăŁăŠă„ăŸă™ă€‚ăă‚Œăžă‚ŒăźăƒŹăƒ™ăƒ«ïŒˆç‰ˆïŒ‰ăźćŸșæș–は、[APIć€‰æ›Žăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)ă«è©łçŽ°ăŒèš˜èŒ‰ă•ă‚ŒăŠă„ăŸă™ă€‚äž‹èš˜ă«ç°Ąæœ”ă«ăŸăšă‚ăŸă™: +異ăȘă‚‹ăƒăƒŒă‚žăƒ§ăƒłăźAPIは、異ăȘă‚‹ăƒŹăƒ™ăƒ«ïŒˆç‰ˆïŒ‰ăźćź‰ćźšæ€§ăšă‚”ăƒăƒŒăƒˆă‚’æŒăŁăŠă„ăŸă™ă€‚ăă‚Œăžă‚ŒăźăƒŹăƒ™ăƒ«ïŒˆç‰ˆïŒ‰ăźćŸșæș–は、[APIć€‰æ›Žăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)ă«è©łçŽ°ăŒèš˜èŒ‰ă•ă‚ŒăŠă„ăŸă™ă€‚äž‹èš˜ă«ç°Ąæœ”ă«ăŸăšă‚ăŸă™: - ă‚ąăƒ«ăƒ•ă‚ĄăƒŹăƒ™ăƒ«ïŒˆç‰ˆïŒ‰: - ăƒăƒŒă‚žăƒ§ăƒłćă«`alpha`ă‚’ć«ăżăŸă™ïŒˆäŸ‹ă€`v1alpha1`ïŒ‰ă€‚ diff --git a/content/ja/docs/concepts/overview/working-with-objects/_index.md b/content/ja/docs/concepts/overview/working-with-objects/_index.md index 8661349a3f..d4a9f2e6b6 100755 --- a/content/ja/docs/concepts/overview/working-with-objects/_index.md +++ b/content/ja/docs/concepts/overview/working-with-objects/_index.md @@ -1,5 +1,5 @@ --- -title: "Working with Kubernetes Objects" +title: "Kubernetesたă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«ă€ă„ăŠ" weight: 40 --- diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md new file mode 100644 index 0000000000..8843138e73 --- /dev/null +++ b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -0,0 +1,74 @@ +--- +title: ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăźăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čăƒăƒ„ăƒŒăƒ‹ăƒłă‚° +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="1.14" state="beta" >}} + +[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesăźăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒă§ă™ă€‚ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźăƒŽăƒŒăƒ‰äžŠă«Podをć‰Čă‚Šćœ“ăŠă‚‹èČŹć‹™ăŒă‚ă‚ŠăŸă™ă€‚ + +ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă«ć­˜ćœšă™ă‚‹ăƒŽăƒŒăƒ‰ă§ă€Podたă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°èŠæ±‚ă‚’æș€ăŸă™ă‚‚たはPodă«ćŻŸă—ăŠ_ć‰Čă‚Šćœ“ăŠćŻèƒœ_ ăȘăƒŽăƒŒăƒ‰ăšć‘Œă°ă‚ŒăŸă™ă€‚ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻPodă«ćŻŸă™ă‚‹ć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ă‚’ăżă€ă‘ă€ăă‚Œă‚‰ăźć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ă«ă‚čă‚łă‚ąă‚’ă€ă‘ăŸă™ă€‚ăăźäž­ă‹ă‚‰æœ€ă‚‚é«˜ă„ă‚čă‚łă‚ąăźăƒŽăƒŒăƒ‰ă‚’éžæŠžă—ă€Podにć‰Čă‚Šćœ“ăŠă‚‹ăŸă‚ăźă„ăă€ă‹ăźé–ąæ•°ă‚’ćźŸèĄŒă—ăŸă™ă€‚ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻ_Binding_ ăšć‘Œă°ă‚Œă‚‹ć‡Šç†äž­ă«ăŠă„ăŠă€APIă‚”ăƒŒăƒăƒŒă«ćŻŸă—ăŠć‰Čă‚Šćœ“ăŠăŒæ±șăŸăŁăŸăƒŽăƒŒăƒ‰ăźæƒ…ć ±ă‚’é€šçŸ„ă—ăŸă™ă€‚ + +ă“ăźăƒšăƒŒă‚žă§ăŻă€ć€§èŠæšĄăźKubernetesă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă‘ă‚‹ăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čæœ€é©ćŒ–ăźăŸă‚ăźăƒăƒ„ăƒŒăƒ‹ăƒłă‚°ă«ă€ă„ăŠèȘŹæ˜Žă—ăŸă™ă€‚ + +{{% /capture %}} + +{{% capture body %}} + +## ă‚čă‚łă‚ąä»˜ă‘ă™ă‚‹ăƒŽăƒŒăƒ‰ăźć‰Č搈 + +Kubernetes 1.12ä»„ć‰ă§ăŻă€Kube-schedulerăŒă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźć…šăŠăźăƒŽăƒŒăƒ‰ă«ćŻŸă—ăŠć‰Čă‚Šćœ“ăŠćŻèƒœă‹ă‚’ăƒă‚§ăƒƒă‚Żă—ă€ćźŸéš›ă«ć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăźă‚čă‚łă‚ąä»˜ă‘ă‚’ă—ăŠă„ăŸă—ăŸă€‚Kubernetes 1.12ă§ăŻæ–°æ©Ÿèƒœă‚’èżœćŠ ă—ă€ă‚ă‚‹æ•°ăźć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăŒèŠ‹ă€ă‹ăŁăŸæ™‚ç‚čで、ć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăźæŽąçŽąă‚’æ­ąă‚ă‚Œă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ă“ă‚Œă«ă‚ˆă‚Šć€§èŠæšĄăȘă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă‘ă‚‹ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăźăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čăŒć‘äžŠă—ăŸă—ăŸă€‚ăăźæ•°ăŻă‚Żăƒ©ă‚čă‚żăƒŒăźă‚”ă‚€ă‚șたć‰Č搈(%)ăšă—ăŠæŒ‡ćźšă•ă‚ŒăŸă™ă€‚ă“ăźć‰Č搈は`percentageOfNodesToScore`べいうă‚Șăƒ—ă‚·ăƒ§ăƒłăźèš­ćźšé …ç›źă«ă‚ˆăŁăŠæŒ‡ćźšćŻèƒœă§ă™ă€‚ă“ăźć€€ăźçŻ„ć›Čは1から100ăŸă§ă§ă™ă€‚100ă‚ˆă‚Šć€§ăă„ć€€ăŻ100%ăšă—ăŠæ‰±ă‚ă‚ŒăŸă™ă€‚0ă‚’æŒ‡ćźšă—ăŸăšăăŻă€ă“ăźèš­ćźšă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’æŒ‡ćźšă—ăȘă„ă‚‚ăźăšă—ăŠæ‰±ă‚ă‚ŒăŸă™ă€‚Kubernetes 1.14ă§ăŻă€ă“ăźć€€ăŒæŒ‡ćźšă•ă‚ŒăŠă„ăȘいべきは、ă‚čă‚łă‚ąä»˜ă‘ă™ă‚‹ăƒŽăƒŒăƒ‰ăźć‰Čćˆă‚’ă‚Żăƒ©ă‚čă‚żăƒŒăźă‚”ă‚€ă‚șにćŸșいいおæ±șćźšă™ă‚‹ăŸă‚ăźæ©Ÿæ§‹ăŒă‚ă‚ŠăŸă™ă€‚ă“ăźæ©Ÿæ§‹ă§ăŻ100ăƒŽăƒŒăƒ‰ăźă‚Żăƒ©ă‚čă‚żăƒŒă«ćŻŸă—ăŠăŻ50%たć‰Č搈べするようăȘç·šćœąăȘćŒă‚’äœżç”šă—ăŸă™ă€‚5000ăƒŽăƒŒăƒ‰ăźă‚Żăƒ©ă‚čă‚żăƒŒă«ćŻŸă—ăŠăŻ10%ずăȘă‚ŠăŸă™ă€‚è‡Ș拕で缗ć‡șされるć‰Čćˆăźæœ€äœŽć€€ăŻ5%ずăȘă‚ŠăŸă™ă€‚èš€ă„æ›ăˆă‚‹ăšă€ă‚Żăƒ©ă‚čă‚żăƒŒăźèŠæšĄăŒă©ă‚Œă ă‘ć€§ăăăŠă‚‚ă€ăƒŠăƒŒă‚¶ăƒŒăŒă“ăźć€€ă‚’5æœȘæș€ă«èš­ćźšă—ăȘい限りă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻć°‘ăȘくども5%ăźă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźăƒŽăƒŒăƒ‰ă‚’ă‚čă‚łă‚ąä»˜ă‘ă™ă‚‹ă“ăšă«ăȘă‚ŠăŸă™ă€‚ + +`percentageOfNodesToScore`た怀を50%ă«èš­ćźšă™ă‚‹äŸ‹ăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha1 +kind: KubeSchedulerConfiguration +algorithmSource: + provider: DefaultProvider + +... + +percentageOfNodesToScore: 50 +``` + +{{< note >}} +ć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăŒ50æœȘæș€ăźă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă„ăŠăŻă€ć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăźæŽąçŽąă‚’æ­ąă‚ă‚‹ă»ă©ăƒŽăƒŒăƒ‰ăŒć€šăăȘいため、ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻć…šăŠăźăƒŽăƒŒăƒ‰ă‚’ăƒă‚§ăƒƒă‚Żă—ăŸă™ă€‚ +{{< /note >}} + +**ă“ăźæ©Ÿèƒœă‚’ç„ĄćŠčă«ă™ă‚‹ăŸă‚ă«ăŻ**、`percentageOfNodesToScore`を100ă«èš­ćźšă—ăŠăă ă•ă„ă€‚ + + +### percentageOfNodesToScoreăźăƒăƒ„ăƒŒăƒ‹ăƒłă‚° + +`percentageOfNodesToScore`は1から100ぼ間ぼ範ć›Čă§ă‚ă‚‹ćż…èŠăŒă‚ă‚Šă€ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ăŻă‚Żăƒ©ă‚čă‚żăƒŒăźă‚”ă‚€ă‚șにćŸșă„ă„ăŠèšˆçź—ă•ă‚ŒăŸă™ă€‚ăŸăŸă€ă‚Żăƒ©ă‚čă‚żăƒŒăźă‚”ă‚€ă‚șăźæœ€ć°ć€€ăŻ50ăƒŽăƒŒăƒ‰ăšăƒăƒŒăƒ‰ă‚łăƒŒăƒ‰ă•ă‚ŒăŠă„ăŸă™ă€‚ă“ă‚ŒăŻæ•°ç™ŸăźăƒŽăƒŒăƒ‰ă‚’æŒă€ă‚ˆă†ăȘă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă„ăŠă“ăźć€€ă‚’50ă‚ˆă‚ŠäœŽă„ć€€ă«ć€‰æ›Žă—ăŠă‚‚ă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŒæ€œć‡șするć‰Čă‚Šćœ“ăŠćŻèƒœăȘăƒŽăƒŒăƒ‰ăźæ•°ă«ć€§ăăȘćœ±éŸżă‚’äžŽăˆăȘă„ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ă“ăźă‚Șăƒ—ă‚·ăƒ§ăƒłăŻæ„ć›łçš„ăȘă‚‚ăźă§ă™ă€‚ăăźç†ç”±ăšă—ăŠăŻă€ć°èŠæšĄăźă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă„ăŠăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čă‚’è‘—ă—ăæ”čć–„ă™ă‚‹ćŻèƒœæ€§ăŒäœŽă„ăŸă‚ă§ă™ă€‚1000ăƒŽăƒŒăƒ‰ă‚’è¶…ăˆă‚‹ć€§èŠæšĄăȘă‚Żăƒ©ă‚čă‚żăƒŒă§ă“ăźć€€ă‚’äœŽăèš­ćźšă™ă‚‹ăšă€ăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čăŒè‘—ă—ăæ”čć–„ă•ă‚Œă‚‹ćŻèƒœæ€§ăŒă‚ă‚ŠăŸă™ă€‚ + +ă“ăźć€€ă‚’èš­ćźšă™ă‚‹éš›ă«è€ƒæ…źă™ă‚‹ăčăé‡èŠăȘæłšæ„äș‹é …ずしお、ć‰Čă‚Šćœ“ăŠćŻèƒœăƒŽăƒŒăƒ‰ăźăƒă‚§ăƒƒă‚ŻćŻŸè±ĄăźăƒŽăƒŒăƒ‰ăŒć°‘ăȘă„ăšă€äž€éƒšăźăƒŽăƒŒăƒ‰ăŻPodたć‰Čă‚Šćœ“ăŠăźăŸă‚ă«ă‚čコケăƒȘングされăȘくăȘă‚ŠăŸă™ă€‚ç”æžœăšă—ăŠă€é«˜ă„ă‚čă‚łă‚ąă‚’ă€ă‘ă‚‰ă‚Œă‚‹ćŻèƒœæ€§ăźă‚ă‚‹ăƒŽăƒŒăƒ‰ăŒă‚čコケăƒȘăƒłă‚°ăƒ•ă‚§ăƒŒă‚șă«æžĄă•ă‚Œă‚‹ă“ăšăŒă‚ă‚ŠăŸă›ă‚“ă€‚ă“ă‚Œă«ă‚ˆă‚Šă€Podăźé…çœźăŒç†æƒłçš„ăȘもぼでăȘくăȘă‚ŠăŸă™ă€‚ă—ăŸăŒăŁăŠă€ă“ăźć€€ă‚’ă‹ăȘă‚ŠäœŽă„ć‰Čćˆă«èš­ćźšă™ăčăă§ăŻă‚ă‚ŠăŸă›ă‚“ă€‚äž€èˆŹçš„ăȘç”Œéš“ć‰‡ăšă—ăŠă€ă“ăźć€€ă‚’10æœȘæș€ă«èš­ćźšă—ăȘいこべです。ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăźă‚čăƒ«ăƒŒăƒ—ăƒƒăƒˆăŒă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă«ăšăŁăŠè‡Žć‘œçš„ă§ă€ăƒŽăƒŒăƒ‰ăźă‚čコケăƒȘăƒłă‚°ăŒé‡èŠă§ăȘă„ăšăăźăżă€ă“ăźć€€ă‚’äœŽăèš­ćźšă™ă‚‹ăčăă§ă™ă€‚èš€ă„ă‹ăˆă‚‹ăšă€ć‰Čă‚Šćœ“ăŠćŻèƒœăȘ限り、PodăŻä»»æ„ăźăƒŽăƒŒăƒ‰äžŠă§çšŒćƒă•ă›ă‚‹ăźăŒć„œăŸă—ă„ă§ă™ă€‚ + +ă‚Żăƒ©ă‚čă‚żăƒŒăŒæ•°ç™ŸăźăƒŽăƒŒăƒ‰ă‚’æŒă€ć Žćˆă‚„ăă‚Œă«æș€ăŸăȘă„ć Žćˆă§ă‚‚ă€ă“ăźèš­ćźšă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ă‚’äœŽăă™ă‚‹ăźă‚’æŽšć„šă—ăŸă›ă‚“ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ă‚’äœŽăă—ăŠă‚‚ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăźăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čを性ćč…にæ”čć–„ă™ă‚‹ă“ăšăŻă‚ă‚ŠăŸă›ă‚“ă€‚ + +### ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻă©ăźă‚ˆă†ă«ăƒŽăƒŒăƒ‰ă‚’æŽąçŽąă™ă‚‹ă‹ + +ă“ăźă‚»ă‚Żă‚·ăƒ§ăƒłă§ăŻă€ă“ăźæ©Ÿèƒœăźć†…éƒšăźè©łçŽ°ă‚’ç†è§Łă—ăŸă„äșș搑けにăȘă‚ŠăŸă™ă€‚ + +ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźć…šăŠăźăƒŽăƒŒăƒ‰ă«ćŻŸă—ăŠćčłç­‰ă«Podたć‰Čă‚Šćœ“ăŠăźćŻèƒœæ€§ă‚’æŒăŸă›ă‚‹ăŸă‚ă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻăƒ©ă‚Šăƒłăƒ‰ăƒ­ăƒ“ăƒłæ–čćŒă§ăƒŽăƒŒăƒ‰ă‚’æŽąçŽąă—ăŸă™ă€‚è€‡æ•°ăźăƒŽăƒŒăƒ‰ăźé…ćˆ—ă«ăȘăŁăŠă„ă‚‹ă‚€ăƒĄăƒŒă‚žă§ă™ă€‚ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻăăźé…ćˆ—ăźć…ˆé ­ă‹ă‚‰æŽąçŽąă‚’é–‹ć§‹ă—ă€`percentageOfNodesToScore`ă«ă‚ˆăŁăŠæŒ‡ćźšă•ă‚ŒăŸæ•°ăźăƒŽăƒŒăƒ‰ă‚’æ€œć‡șă™ă‚‹ăŸă§ă€ć‰Čă‚Šćœ“ăŠćŻèƒœă‹ă©ă†ă‹ă‚’ăƒă‚§ăƒƒă‚Żă—ăŠă„ăăŸă™ă€‚æŹĄăźPodでは、ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻć‰ăźPodたć‰Čă‚Šćœ“ăŠć‡Šç†ă§ăƒă‚§ăƒƒă‚Żă—ăŸăšă“ă‚ă‹ă‚‰æŽąçŽąă‚’ć†é–‹ă—ăŸă™ă€‚ + +ăƒŽăƒŒăƒ‰ăŒè€‡æ•°ăźă‚ŸăƒŒăƒłă«ć­˜ćœšă™ă‚‹ăšăă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻæ§˜ă€…ăȘă‚ŸăƒŒăƒłăźăƒŽăƒŒăƒ‰ă‚’æŽąçŽąă—ăŠă€ç•°ăȘă‚‹ă‚ŸăƒŒăƒłăźăƒŽăƒŒăƒ‰ăŒć‰Čă‚Šćœ“ăŠćŻèƒœă‹ă©ă†ă‹ăźăƒă‚§ăƒƒă‚ŻćŻŸè±Ąă«ăȘă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚äŸ‹ăˆă°2ă€ăźă‚ŸăƒŒăƒłă«6ă€ăźăƒŽăƒŒăƒ‰ăŒă‚ă‚‹ć Žćˆă‚’è€ƒăˆăŸă™ă€‚ + +``` +Zone 1: Node 1, Node 2, Node 3, Node 4 +Zone 2: Node 5, Node 6 +``` + +ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŻă€äž‹èš˜ăźé †ç•Șă§ăƒŽăƒŒăƒ‰ăźć‰Čă‚Šćœ“ăŠćŻèƒœæ€§ă‚’è©•äŸĄă—ăŸă™ă€‚ + +``` +Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 +``` + +ć…šăŠăźăƒŽăƒŒăƒ‰ăźăƒă‚§ăƒƒă‚Żă‚’ç”‚ăˆăŸă‚‰ă€1ç•Șç›źăźăƒŽăƒŒăƒ‰ă«æˆ»ăŁăŠăƒă‚§ăƒƒă‚Żă‚’ă—ăŸă™ă€‚ + +{{% /capture %}} diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md new file mode 100644 index 0000000000..1b3ac2e810 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -0,0 +1,420 @@ +--- +title: ă‚”ăƒŒăƒ“ă‚čべケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźæŽ„ç¶š +content_template: templates/concept +weight: 30 +--- + + +{{% capture overview %}} + +## ă‚łăƒłăƒ†ăƒŠă‚’æŽ„ç¶šă™ă‚‹ăŸă‚ăźKubernetesăƒąăƒ‡ăƒ« + +ç¶™ç¶šçš„ă«ćźŸèĄŒă•ă‚Œă€è€‡èŁœă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźæș–ć‚™ăŒă§ăăŸăźă§ă€ăƒăƒƒăƒˆăƒŻăƒŒă‚ŻäžŠă§ć…Źé–‹ă™ă‚‹ă“ăšăŒćŻèƒœă«ăȘă‚ŠăŸă™ă€‚ +KubernetesăźăƒăƒƒăƒˆăƒŻăƒŒă‚Żăźă‚ąăƒ—ăƒ­ăƒŒăƒă«ă€ă„ăŠèȘŹæ˜Žă™ă‚‹ć‰ă«ă€Dockerăźă€Œé€šćžžăźă€ăƒăƒƒăƒˆăƒŻăƒŒă‚Żæ‰‹æł•ăšæŻ”èŒƒă™ă‚‹ă“ăšăŒé‡èŠă§ă™ă€‚ + +ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻă€Dockerはホă‚čăƒˆăƒ—ăƒ©ă‚€ăƒ™ăƒŒăƒˆăƒăƒƒăƒˆăƒŻăƒŒă‚­ăƒłă‚°ă‚’äœżç”šă™ă‚‹ăŸă‚ă€ă‚łăƒłăƒ†ăƒŠăŻćŒă˜ăƒžă‚·ăƒłäžŠă«ă‚ă‚‹ć Žćˆă«ăźăżä»–ăźă‚łăƒłăƒ†ăƒŠăšé€šäżĄă§ăăŸă™ă€‚ +Dockeră‚łăƒłăƒ†ăƒŠăŒăƒŽăƒŒăƒ‰é–“ă§é€šäżĄă™ă‚‹ă«ăŻă€ăƒžă‚·ăƒłăźIPケドレă‚čă«ăƒăƒŒăƒˆă‚’ć‰Čă‚Šćœ“ăŠăŠă‹ă‚‰ă€ă‚łăƒłăƒ†ăƒŠă«è»ąé€ăŸăŸăŻăƒ—ăƒ­ă‚­ă‚·ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +ă“ă‚ŒăŻæ˜Žă‚‰ă‹ă«ă€ă‚łăƒłăƒ†ăƒŠăŒäœżç”šă™ă‚‹ăƒăƒŒăƒˆă‚’éžćžžă«æ…Žé‡ă«èȘżæ•Žă™ă‚‹ă‹ă€ăƒăƒŒăƒˆă‚’拕的にć‰Čă‚Šćœ“ăŠă‚‹ćż…èŠăŒă‚ă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ + +è€‡æ•°ăźé–‹ç™șè€…é–“ă§ăƒăƒŒăƒˆă‚’èȘżæ•Žă™ă‚‹ă“ăšăŻć€§èŠæšĄă«èĄŒă†ă“ăšăŻéžćžžă«é›Łă—ăă€ăƒŠăƒŒă‚¶ăƒŒăŒćˆ¶ćŸĄă§ăăȘă„ă‚Żăƒ©ă‚čă‚żăƒŒăƒŹăƒ™ăƒ«ăźć•éĄŒă«ă•ă‚‰ă•ă‚ŒăŸă™ă€‚ +Kubernetesă§ăŻă€ă©ăźăƒ›ă‚čăƒˆă§çšŒćƒă™ă‚‹ă‹ă«é–ąă‚ă‚‰ăšă€PodăŒä»–ăźPodăšé€šäżĄă§ăă‚‹ăšæƒłćźšă—ăŠă„ăŸă™ă€‚ +すăčおたPodに狏è‡Șăźă‚Żăƒ©ă‚čă‚żăƒŒăƒ—ăƒ©ă‚€ăƒ™ăƒŒăƒˆIPケドレă‚čă‚’ä»˜äžŽă™ă‚‹ăŸă‚ă€Pod間ぼăƒȘăƒłă‚Żă‚’æ˜Žç€șçš„ă«äœœæˆă—ăŸă‚Šă€ă‚łăƒłăƒ†ăƒŠăƒăƒŒăƒˆă‚’ăƒ›ă‚čăƒˆăƒăƒŒăƒˆă«ăƒžăƒƒăƒ—ă—ăŸă‚Šă™ă‚‹ćż…èŠăŻă‚ă‚ŠăŸă›ă‚“ă€‚ +これは、Pod憅ぼコンテナがすăčおlocalhostぼ盾äș’ăźăƒăƒŒăƒˆă«ćˆ°é”ă§ăă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźă™ăčおたPodがNATăȘしで盾äș’にèȘè­˜ă§ăă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ +ă“ăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆăźæź‹ă‚Šăźéƒšćˆ†ă§ăŻă€ă“ăźă‚ˆă†ăȘăƒăƒƒăƒˆăƒŻăƒŒă‚Żăƒąăƒ‡ăƒ«ă§äżĄé Œă§ăă‚‹ă‚”ăƒŒăƒ“ă‚čă‚’ćźŸèĄŒă™ă‚‹æ–čæł•ă«ă€ă„ăŠè©łă—ăèȘŹæ˜Žă—ăŸă™ă€‚ + +ă“ăźă‚Źă‚€ăƒ‰ă§ăŻă€ă‚·ăƒłăƒ—ăƒ«ăȘnginxă‚”ăƒŒăƒăƒŒă‚’äœżç”šă—ăŠæŠ‚ćż”ćźŸèšŒă‚’ç€șă—ăŸă™ă€‚ +搌じ掟扇が、より漌慹ăȘ[Jenkins CIケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒł](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)ă§ć…·äœ“ćŒ–ă•ă‚ŒăŠă„ăŸă™ă€‚ + +{{% /capture %}} + +{{% capture body %}} + +## Podă‚’ă‚Żăƒ©ă‚čă‚żăƒŒă«ć…Źé–‹ă™ă‚‹ + +ć‰ăźäŸ‹ă§ăƒăƒƒăƒˆăƒŻăƒŒă‚Żăƒąăƒ‡ăƒ«ă‚’çŽčä»‹ă—ăŸă—ăŸăŒă€ć†ćșŠăƒăƒƒăƒˆăƒŻăƒŒă‚ŻăźèŠłç‚čに焊ç‚čă‚’ćœ“ăŠăŸă—ă‚‡ă†ă€‚ +nginx Podă‚’äœœæˆă—ă€ă‚łăƒłăƒ†ăƒŠăƒăƒŒăƒˆăźä»•æ§˜ă‚’æŒ‡ćźšă—ăŠă„ă‚‹ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ + +{{< codenew file="service/networking/run-my-nginx.yaml" >}} + +ă“ă‚Œă«ă‚ˆă‚Šă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźă©ăźăƒŽăƒŒăƒ‰ă‹ă‚‰ă§ă‚‚ă‚ąă‚Żă‚»ă‚čă§ăă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă™ă€‚ +PodăŒćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ăƒŽăƒŒăƒ‰ă‚’çąșèȘă—ăŸă™: + +```shell +kubectl apply -f ./run-my-nginx.yaml +kubectl get pods -l run=my-nginx -o wide +``` +``` +NAME READY STATUS RESTARTS AGE IP NODE +my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m +my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd +``` + +PodたIPをçąșèȘă—ăŸă™: + +```shell +kubectl get pods -l run=my-nginx -o yaml | grep podIP + podIP: 10.244.3.4 + podIP: 10.244.2.5 +``` + +ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźä»»æ„ăźăƒŽăƒŒăƒ‰ă«SSHæŽ„ç¶šă—ă€äžĄæ–čたIPにcurlæŽ„ç¶šă§ăă‚‹ăŻăšă§ă™ă€‚ +ă‚łăƒłăƒ†ăƒŠăŻăƒŽăƒŒăƒ‰ă§ăƒăƒŒăƒˆ80ă‚’äœżç”š**しどいăȘい**ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ +ăŸăŸă€Podă«ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ăƒ«ăƒŒăƒ†ă‚Łăƒłă‚°ă™ă‚‹ç‰č戄ăȘNATăƒ«ăƒŒăƒ«ă‚‚ă‚ă‚ŠăŸă›ă‚“ă€‚ +ă€ăŸă‚Šă€ćŒă˜containerPortă‚’äœżç”šă—ăŠćŒă˜ăƒŽăƒŒăƒ‰ă§è€‡æ•°ăźnginx Podă‚’ćźŸèĄŒă—ă€IPă‚’äœżç”šă—ăŠă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźä»–ăźPodă‚„ăƒŽăƒŒăƒ‰ă‹ă‚‰ăă‚Œă‚‰ă«ă‚ąă‚Żă‚»ă‚čă§ăăŸă™ă€‚ +DockerăšćŒæ§˜ă«ă€ăƒăƒŒăƒˆăŻćŒ•ăç¶šăăƒ›ă‚čăƒˆăƒŽăƒŒăƒ‰ăźă‚€ăƒłă‚żăƒŒăƒ•ă‚§ă‚€ă‚čă«ć…Źé–‹ă§ăăŸă™ăŒă€ăƒăƒƒăƒˆăƒŻăƒŒă‚Żăƒąăƒ‡ăƒ«ă«ă‚ˆă‚Šă€ă“ăźćż…èŠæ€§ăŻæ čæœŹçš„ă«æž›ć°‘ă—ăŸă™ă€‚ + +èˆˆć‘łăŒă‚ă‚Œă°ă€ă“ă‚Œă‚’[ă©ăźă‚ˆă†ă«é”æˆă™ă‚‹ă‹](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)ă«ă€ă„ăŠè©łă—ăèȘ­ă‚€ă“ăšăŒă§ăăŸă™ă€‚ + +## Serviceă‚’äœœæˆă™ă‚‹ + +ăăźăŸă‚ă€ăƒ•ăƒ©ăƒƒăƒˆă§ă‚Żăƒ©ă‚čă‚żăƒŒć…šäœ“ăźă‚ąăƒ‰ăƒŹă‚čç©ș間でnginxă‚’ćźŸèĄŒă™ă‚‹PodăŒă‚ă‚ŠăŸă™ă€‚ +ç†è«–çš„ă«ăŻă€ă“ă‚Œă‚‰ăźPodăšç›ŽæŽ„é€šäżĄă™ă‚‹ă“ăšăŒă§ăăŸă™ăŒă€ăƒŽăƒŒăƒ‰ăŒćœæ­ąă™ă‚‹ăšă©ă†ăȘă‚ŠăŸă™ă‹ïŒŸ +PodăŻăă‚Œă§æ­»ă«ă€Deploymentは異ăȘるIPă‚’æŒă€æ–°ă—ă„ă‚‚ăźă‚’äœœæˆă—ăŸă™ă€‚ +これは、ServiceăŒè§Łæ±șする敏題です。 + +Kubernetes ServiceăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźă©ă“ă‹ă§ćźŸèĄŒă•ă‚Œă‚‹Podăźè«–ç†ă‚»ăƒƒăƒˆă‚’ćźšçŸ©ă™ă‚‹æŠœè±ĄćŒ–ă§ă‚ă‚Šă€ă™ăčăŠćŒă˜æ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ +äœœæˆă•ă‚Œă‚‹ăšă€ć„Serviceă«ăŻäž€æ„ăźIPケドレă‚č(clusterIPăšă‚‚ć‘Œă°ă‚ŒăŸă™)がć‰Čă‚Šćœ“ăŠă‚‰ă‚ŒăŸă™ă€‚ +こぼケドレă‚čはServiceăźæœ‰ćŠčæœŸé–“ă«é–ąé€Łä»˜ă‘ă‚‰ă‚ŒăŠăŠă‚Šă€ServiceăŒć‹•äœœă—ăŠă„ă‚‹é–“ăŻć€‰æ›Žă•ă‚ŒăŸă›ă‚“ă€‚ +Podは、Serviceăšé€šäżĄă™ă‚‹ă‚ˆă†ă«æ§‹æˆă§ăă€Serviceまぼ通信は、ServiceăźăƒĄăƒłăƒăƒŒă§ă‚ă‚‹Podにè‡Ș拕的にèČ è·ćˆ†æ•Łă•ă‚Œă‚‹ă“ăšă‚’èȘè­˜ă§ăăŸă™ă€‚ + +2぀たnginxレプăƒȘă‚«ăźă‚”ăƒŒăƒ“ă‚čを`kubectl exposed`ă§äœœæˆă§ăăŸă™: + +```shell +kubectl expose deployment/my-nginx +``` +``` +service/my-nginx exposed +``` + +ă“ă‚ŒăŻæŹĄăźyamlを`kubectl apply -f`するこべべ搌等です: + +{{< codenew file="service/networking/nginx-svc.yaml" >}} + +ă“ăźä»•æ§˜ăŻă€`runmy-nginx`ăƒ©ăƒ™ăƒ«ă‚’æŒă€ä»»æ„ăźPodたTCPăƒăƒŒăƒˆ80ă‚’ă‚żăƒŒă‚Čăƒƒăƒˆăšă™ă‚‹ă‚”ăƒŒăƒ“ă‚čă‚’äœœæˆă—ă€æŠœè±ĄćŒ–ă•ă‚ŒăŸă‚”ăƒŒăƒ“ă‚čăƒăƒŒăƒˆă§Podă‚’ć…Źé–‹ă—ăŸă™(`targetPort`:ăŻă‚łăƒłăƒ†ăƒŠăŒăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ć—äżĄă™ă‚‹ăƒăƒŒăƒˆă€`port`:ăŻæŠœè±ĄćŒ–ă•ă‚ŒăŸServiceăźăƒăƒŒăƒˆă§ă‚ă‚Šă€ä»–ăźPodがServiceぞたスクセă‚čă«äœżç”šă™ă‚‹ä»»æ„ăźăƒăƒŒăƒˆă«ă™ă‚‹ă“ăšăŒă§ăăŸă™)。 +ă‚”ăƒŒăƒ“ă‚čćźšçŸ©ă§ă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ă‚‹ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźăƒȘă‚čトは[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) APIă‚Șブゾェクトを揂照しどください。 + +ServiceをçąșèȘă—ăŸă™: + +```shell +kubectl get svc my-nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx ClusterIP 10.0.162.149 80/TCP 21s +``` + +ć‰èż°ăźă‚ˆă†ă«ă€ServiceはPodăźă‚°ăƒ«ăƒŒăƒ—ă«ă‚ˆăŁăŠă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ăŸă™ă€‚ +これらぼPodăŻă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚’é€šă˜ăŠć…Źé–‹ă•ă‚ŒăŸă™ă€‚ +Serviceăźă‚»ăƒŹă‚Żă‚żăƒŒăŻç¶™ç¶šçš„ă«è©•äŸĄă•ă‚Œă€ç”æžœăŻ`my-nginx`べいう損才ぼEndpointă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă«POSTă•ă‚ŒăŸă™ă€‚ +PodăŒç”‚äș†ă™ă‚‹ăšă€ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‹ă‚‰è‡Șć‹•çš„ă«ć‰Šé™€ă•ă‚Œă€Serviceăźă‚»ăƒŹă‚Żă‚żăƒŒă«äž€è‡Žă™ă‚‹æ–°ă—ă„Podがè‡Șć‹•çš„ă«ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă«èżœćŠ ă•ă‚ŒăŸă™ă€‚ +ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚’çąșèȘă—、IPăŒæœ€ćˆăźă‚čăƒ†ăƒƒăƒ—ă§äœœæˆă•ă‚ŒăŸPodべ搌じであるこべをçąșèȘă—ăŸă™: + +```shell +kubectl describe svc my-nginx +``` +``` +Name: my-nginx +Namespace: default +Labels: run=my-nginx +Annotations: +Selector: run=my-nginx +Type: ClusterIP +IP: 10.0.162.149 +Port: 80/TCP +Endpoints: 10.244.2.5:80,10.244.3.4:80 +Session Affinity: None +Events: +``` +```shell +kubectl get ep my-nginx +``` +``` +NAME ENDPOINTS AGE +my-nginx 10.244.2.5:80,10.244.3.4:80 1m +``` + +ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźä»»æ„ăźăƒŽăƒŒăƒ‰ă‹ă‚‰ă€`:`でnginx ServiceにcurlæŽ„ç¶šă§ăă‚‹ă‚ˆă†ă«ăȘă‚ŠăŸă—ăŸă€‚ +Service IPăŻćźŒć…šă«ä»źæƒłçš„ăȘもぼで、ホă‚čăƒˆćŽăźăƒăƒƒăƒˆăƒŻăƒŒă‚Żă«ăŻæŽ„ç¶šă§ăăȘă„ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ +ă“ăźä»•ç”„ăżă«èˆˆć‘łăŒă‚ă‚‹ć ŽćˆăŻă€[ă‚”ăƒŒăƒ“ă‚čăƒ—ăƒ­ă‚­ă‚·ăƒŒ](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)ăźè©łçŽ°ă‚’ăŠèȘ­ăżăă ă•ă„。 + +## Serviceにスクセă‚čする + +KubernetesăŻă€ç’°ćąƒć€‰æ•°ăšDNSた2ă€ăźäž»èŠăȘServiceæ€œçŽąăƒąăƒŒăƒ‰ă‚’ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ +ć‰è€…ăŻăăźăŸăŸäœżç”šă§ăă€ćŸŒè€…ăŻ[CoreDNSă‚Żăƒ©ă‚čタケドă‚Șン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)ă‚’ćż…èŠăšă—ăŸă™ă€‚ +{{< note >}} +ă‚”ăƒŒăƒ“ă‚čç’°ćąƒć€‰æ•°ăŒæœ›ăŸă—ăăȘい栮搈(äșˆæƒłă•ă‚Œă‚‹ăƒ—ăƒ­ă‚°ăƒ©ăƒ ć€‰æ•°ăšèĄçȘă™ă‚‹ćŻèƒœæ€§ăŒă‚ă‚‹ă€ć‡Šç†ă™ă‚‹ć€‰æ•°ăŒć€šă™ăŽă‚‹ă€DNSăźăżă‚’äœżç”šă™ă‚‹ăȘど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`ăƒ•ăƒ©ă‚°ă‚’`false`ă«èš­ćźšă™ă‚‹ă“ăšă§ă“ăźăƒąăƒŒăƒ‰ă‚’ç„ĄćŠčă«ă§ăăŸă™ă€‚ +{{< /note >}} + + +### ç’°ćąƒć€‰æ•° + +ăƒŽăƒŒăƒ‰ă§PodăŒćźŸèĄŒă•ă‚Œă‚‹ăšă€kubeletはケクティブăȘć„ă‚”ăƒŒăƒ“ă‚čăźç’°ćąƒć€‰æ•°ăźă‚»ăƒƒăƒˆă‚’èżœćŠ ă—ăŸă™ă€‚ +ă“ă‚Œă«ă‚ˆă‚Šă€é †ćșä»˜ă‘ăźć•éĄŒăŒç™șç”Ÿă—ăŸă™ă€‚ +理由をçąșèȘă™ă‚‹ă«ăŻă€ćźŸèĄŒäž­ăźnginx Podぼ環汃をèȘżăčăŸă™(PodćăŻç’°ćąƒă«ă‚ˆăŁăŠç•°ăȘă‚ŠăŸă™): + +```shell +kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE +``` +``` +KUBERNETES_SERVICE_HOST=10.0.0.1 +KUBERNETES_SERVICE_PORT=443 +KUBERNETES_SERVICE_PORT_HTTPS=443 +``` + +ă‚”ăƒŒăƒ“ă‚čă«èš€ćŠăŒăȘă„ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ă“ă‚ŒăŻă€ă‚”ăƒŒăƒ“ă‚čăźć‰ă«ăƒŹăƒ—ăƒȘă‚«ă‚’äœœæˆă—ăŸăŸă‚ă§ă™ă€‚ +これぼもう1ă€ăźæŹ ç‚čは、ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŒäžĄæ–čたPodă‚’ćŒă˜ăƒžă‚·ăƒłă«é…çœźă—ă€ă‚”ăƒŒăƒ“ă‚čăŒćœæ­ąă—ăŸć Žćˆă«ă‚”ăƒŒăƒ“ă‚čć…šäœ“ăŒăƒ€ă‚Šăƒłă™ă‚‹ćŻèƒœæ€§ăŒă‚ă‚‹ă“ăšă§ă™ă€‚ +2぀たPodă‚’ćŒ·ćˆ¶ç”‚äș†ă—、DeploymentăŒăă‚Œă‚‰ă‚’ć†äœœæˆă™ă‚‹ăźă‚’ćŸ…ă€ă“ăšă§ă€ă“ă‚Œă‚’æ­Łă—ă„æ–čæł•ă§ćźŸèĄŒă§ăăŸă™ă€‚ +ä»Šć›žăŻă€ă‚”ăƒŒăƒ“ă‚čはレプăƒȘă‚«ăźă€Œć‰ă€ă«ć­˜ćœšă—ăŸă™ă€‚ +ă“ă‚Œă«ă‚ˆă‚Šă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăƒŹăƒ™ăƒ«ăźă‚”ăƒŒăƒ“ă‚čがPodにćșƒăŒă‚Š(すăčăŠăźăƒŽăƒŒăƒ‰ăźćźč量が等しい栮搈)ă€é©ćˆ‡ăȘç’°ćąƒć€‰æ•°ăŒæäŸ›ă•ă‚ŒăŸă™: + +```shell +kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2; + +kubectl get pods -l run=my-nginx -o wide +``` +``` +NAME READY STATUS RESTARTS AGE IP NODE +my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd +my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m +``` + +PodăŻćŒ·ćˆ¶ç”‚äș†ă•ă‚ŒăŠć†äœœæˆă•ă‚Œă‚‹ăŸă‚ă€ç•°ăȘă‚‹ćć‰ăŒä»˜ă„ăŠă„ă‚‹ă“ăšă«æ°—ä»˜ăă§ă—ă‚‡ă†ă€‚ + +```shell +kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE +``` +``` +KUBERNETES_SERVICE_PORT=443 +MY_NGINX_SERVICE_HOST=10.0.162.149 +KUBERNETES_SERVICE_HOST=10.0.0.1 +MY_NGINX_SERVICE_PORT=80 +KUBERNETES_SERVICE_PORT_HTTPS=443 +``` + +### DNS + +Kubernetesは、DNSćă‚’ä»–ăźServiceにè‡Ș拕的にć‰Čă‚Šćœ“ăŠă‚‹DNSă‚Żăƒ©ă‚čă‚żăƒŒă‚ąăƒ‰ă‚Șăƒłă‚”ăƒŒăƒ“ă‚čă‚’æäŸ›ă—ăŸă™ă€‚ +ă‚Żăƒ©ă‚čă‚żăƒŒă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ă‹ă©ă†ă‹ă‚’çąșèȘă§ăăŸă™: + +```shell +kubectl get services kube-dns --namespace=kube-system +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m +``` + +ćźŸèĄŒă•ă‚ŒăŠă„ăȘい栮搈は、[有ćŠčにする](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)ă“ăšăŒă§ăăŸă™ă€‚ +ă“ăźă‚»ă‚Żă‚·ăƒ§ăƒłăźæź‹ă‚Šăźéƒšćˆ†ă§ăŻă€ćŻżć‘œăźé•·ă„IP(my-nginx)ă‚’æŒă€Serviceべ、そぼIPă«ćć‰ă‚’ć‰Čă‚Šćœ“ăŠăŸDNSă‚”ăƒŒăƒăƒŒ(CoreDNSă‚Żăƒ©ă‚čă‚żăƒŒă‚ąăƒ‰ă‚Șン)ăŒă‚ă‚‹ă“ăšă‚’ć‰æăšă—ăŠă„ă‚‹ăŸă‚ă€æš™æș–çš„ăȘæ–čæł•(gethostbynameăȘど)ă‚’äœżç”šă—ăŠă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźä»»æ„ăźPodからServiceă«é€šäżĄă§ăăŸă™ă€‚ +curlケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă—ăŠă€ă“ă‚Œă‚’ăƒ†ă‚čăƒˆă—ăŠăżăŸă—ă‚‡ă†: + +```shell +kubectl run curl --image=radial/busyboxplus:curl -i --tty +``` +``` +Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false +Hit enter for command prompt +``` + +æŹĄă«ă€Enteră‚­ăƒŒă‚’æŠŒă—ăŠ`nslookup my-nginx`ă‚’ćźŸèĄŒă—ăŸă™: + +```shell +[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 + +Name: my-nginx +Address 1: 10.0.162.149 +``` + +## Serviceを柉慚にする + +ă“ă‚ŒăŸă§ăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă‹ă‚‰nginxă‚”ăƒŒăƒăƒŒă«ă‚ąă‚Żă‚»ă‚čしただけでした。 +ă‚”ăƒŒăƒ“ă‚čă‚’ă‚€ăƒłă‚żăƒŒăƒăƒƒăƒˆă«ć…Źé–‹ă™ă‚‹ć‰ă«ă€é€šäżĄăƒăƒŁăƒăƒ«ăŒćź‰ć…šă§ă‚ă‚‹ă“ăšă‚’çąșèȘă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +ă“ă‚Œă«ăŻă€æŹĄăźă‚‚ăźăŒćż…èŠă§ă™: + +* https甹ぼè‡Șć·±çœČćèšŒæ˜Žæ›ž(æ—ąă«IDèšŒæ˜Žæ›žă‚’æŒăŁăŠă„ă‚‹ć Žćˆă‚’é™€ă) +* èšŒæ˜Žæ›žă‚’äœżç”šă™ă‚‹ă‚ˆă†ă«æ§‹æˆă•ă‚ŒăŸnginxă‚”ăƒŒăƒăƒŒ +* PodăŒèšŒæ˜Žæ›žă«ă‚ąă‚Żă‚»ă‚čă§ăă‚‹ă‚ˆă†ă«ă™ă‚‹[Secret](/docs/concepts/configuration/secret/) + +これらはすăčお[nginx httpsăźäŸ‹](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)ă‹ă‚‰ć–ćŸ—ă§ăăŸă™ă€‚ +ă“ă‚Œă«ăŻăƒ„ăƒŒăƒ«ă‚’ă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +ă“ă‚Œă‚‰ă‚’ă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă—ăŸăăȘă„ć ŽćˆăŻă€ćŸŒă§æ‰‹ć‹•ăźæ‰‹é †ă«ćŸ“ăŁăŠăă ă•ă„ă€‚ă€ăŸă‚Š: + +```shell +make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt +kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt +``` +``` +secret/nginxsecret created +``` +```shell +kubectl get secrets +``` +``` +NAME TYPE DATA AGE +default-token-il9rc kubernetes.io/service-account-token 1 1d +nginxsecret Opaque 2 1m +``` +仄䞋は、(Windows侊ăȘど)makeăźćźŸèĄŒă§ć•éĄŒăŒç™șç”Ÿă—ăŸć Žćˆă«ćźŸèĄŒă™ă‚‹æ‰‹ć‹•ăźæ‰‹é †ă§ă™: + +```shell +# ć…Źé–‹ç§˜ćŻ†é”ăƒšă‚ąă‚’äœœæˆă—ăŸă™ +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" +# ă‚­ăƒŒă‚’base64ă‚šăƒłă‚łăƒŒăƒ‰ă«ć€‰æ›ă—ăŸă™ +cat /d/tmp/nginx.crt | base64 +cat /d/tmp/nginx.key | base64 +``` +才ぼコマンドぼć‡șćŠ›ă‚’äœżç”šă—ăŠă€æŹĄăźă‚ˆă†ă«yamlăƒ•ă‚Ąă‚€ăƒ«ă‚’äœœæˆă—ăŸă™ă€‚ +base64ă§ă‚šăƒłă‚łăƒŒăƒ‰ă•ă‚ŒăŸć€€ăŻă™ăčお1èĄŒă§ă‚ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ + +```yaml +apiVersion: "v1" +kind: "Secret" +metadata: + name: "nginxsecret" + namespace: "default" +data: + nginx.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" + nginx.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K" +``` +ăƒ•ă‚Ąă‚€ăƒ«ă‚’äœżç”šă—ăŠSecretă‚’äœœæˆă—ăŸă™: + +```shell +kubectl apply -f nginxsecrets.yaml +kubectl get secrets +``` +``` +NAME TYPE DATA AGE +default-token-il9rc kubernetes.io/service-account-token 1 1d +nginxsecret Opaque 2 1m +``` + +æŹĄă«ă€nginxレプăƒȘă‚«ă‚’ć€‰æ›Žă—ăŠă€ă‚·ăƒŒă‚ŻăƒŹăƒƒăƒˆăźèšŒæ˜Žæ›žăšServiceă‚’äœżç”šă—ăŠhttpsă‚”ăƒŒăƒăƒŒă‚’è”·ć‹•ă—ă€äžĄæ–čăźăƒăƒŒăƒˆ(80ず443)ă‚’ć…Źé–‹ă—ăŸă™: + +{{< codenew file="service/networking/nginx-secure-app.yaml" >}} + +nginx-secure-appマニフェă‚čăƒˆă«é–ąă™ă‚‹æłšç›źă™ăčきç‚č: + +- ćŒă˜ăƒ•ă‚Ąă‚€ăƒ«ă«DeploymentずServiceた䞥æ–čăŒć«ăŸă‚ŒăŠă„ăŸă™ă€‚ +- [nginxă‚”ăƒŒăƒăƒŒ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)ăŻăƒăƒŒăƒˆ80たHTTPăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żăš443たHTTPSăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ć‡Šç†ă—ă€nginx Serviceは䞥æ–čăźăƒăƒŒăƒˆă‚’ć…Źé–‹ă—ăŸă™ă€‚ +- 搄コンテナは`/etc/nginx/ssl`ă«ăƒžă‚Šăƒłăƒˆă•ă‚ŒăŸăƒœăƒȘăƒ„ăƒŒăƒ ă‚’ä»‹ă—ăŠă‚­ăƒŒă«ă‚ąă‚Żă‚»ă‚čă§ăăŸă™ă€‚ + これは、nginxă‚”ăƒŒăƒăƒŒăŒè”·ć‹•ă™ă‚‹*ć‰ă«*ă‚»ăƒƒăƒˆă‚ąăƒƒăƒ—ă•ă‚ŒăŸă™ă€‚ + +```shell +kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml +``` + +ă“ăźæ™‚ç‚čă§ă€ä»»æ„ăźăƒŽăƒŒăƒ‰ă‹ă‚‰nginxă‚”ăƒŒăƒăƒŒă«ćˆ°é”ă§ăăŸă™ă€‚ + +```shell +kubectl get pods -o yaml | grep -i podip + podIP: 10.244.3.5 +node $ curl -k https://10.244.3.5 +... +

Welcome to nginx!

+``` + +æœ€ćŸŒăźæ‰‹é †ă§curlに`-k`ăƒ‘ăƒ©ăƒĄăƒŒă‚żăƒŒă‚’æŒ‡ćźšă—ăŸă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ +ă“ă‚ŒăŻă€èšŒæ˜Žæ›žăźç”Ÿæˆæ™‚ă«nginxă‚’ćźŸèĄŒă—ăŠă„ă‚‹Podă«ă€ă„ăŠäœ•ă‚‚çŸ„ă‚‰ăȘいためです。 +CNameăźäžäž€è‡Žă‚’ç„ĄèŠ–ă™ă‚‹ă‚ˆă†curlă«æŒ‡ç€șă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +Serviceă‚’äœœæˆă™ă‚‹ă“ăšă«ă‚ˆă‚Šă€èšŒæ˜Žæ›žă§äœżç”šă•ă‚Œă‚‹CNameを、Serviceæ€œçŽąäž­ă«Podă§äœżç”šă•ă‚Œă‚‹ćźŸéš›ăźDNSćă«ăƒȘăƒłă‚Żă—ăŸă—ăŸă€‚ +これをPodからテă‚čăƒˆă—ăŸă—ă‚‡ă†(ç°Ąć˜ă«ă™ă‚‹ăŸă‚ă«ćŒă˜ă‚·ăƒŒă‚ŻăƒŹăƒƒăƒˆă‚’ć†ćˆ©ç”šă—ăŠă„ăŸă™ă€‚PodはServiceにスクセă‚čă™ă‚‹ăŸă‚ă«nginx.crtăźăżă‚’ćż…èŠăšă—ăŸă™): + +{{< codenew file="service/networking/curlpod.yaml" >}} + +```shell +kubectl apply -f ./curlpod.yaml +kubectl get pods -l app=curlpod +``` +``` +NAME READY STATUS RESTARTS AGE +curl-deployment-1515033274-1410r 1/1 Running 0 1m +``` +```shell +kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt +... +Welcome to nginx! +... +``` + +## Serviceを慬開する + +ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźäž€éƒšă§ăŻă€Serviceă‚’ć€–éƒšIPケドレă‚čă«ć…Źé–‹ă—ăŸă„ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ +Kubernetesは、NodePortずLoadBalancerた2぀たæ–čæł•ă‚’ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ +ć‰ăźă‚»ă‚Żă‚·ăƒ§ăƒłă§äœœæˆă—ăŸServiceはすでに`NodePort`ă‚’äœżç”šă—ăŠă„ă‚‹ăŸă‚ă€ăƒŽăƒŒăƒ‰ă«ăƒ‘ăƒ–ăƒȘックIPがあれば、nginx HTTPSレプăƒȘă‚«ăŻă‚€ăƒłă‚żăƒŒăƒăƒƒăƒˆäžŠăźăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ć‡Šç†ă™ă‚‹æș–ć‚™ăŒă§ăăŠă„ăŸă™ă€‚ + +```shell +kubectl get svc my-nginx -o yaml | grep nodePort -C 5 + uid: 07191fb3-f61a-11e5-8ae5-42010af00002 +spec: + clusterIP: 10.0.162.149 + ports: + - name: http + nodePort: 31704 + port: 8080 + protocol: TCP + targetPort: 80 + - name: https + nodePort: 32453 + port: 443 + protocol: TCP + targetPort: 443 + selector: + run: my-nginx +``` +```shell +kubectl get nodes -o yaml | grep ExternalIP -C 1 + - address: 104.197.41.11 + type: ExternalIP + allocatable: +-- + - address: 23.251.152.56 + type: ExternalIP + allocatable: +... + +$ curl https://: -k +... +

Welcome to nginx!

+``` + +ă‚Żăƒ©ă‚Šăƒ‰ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’äœżç”šă™ă‚‹ă‚ˆă†ă«ă‚”ăƒŒăƒ“ă‚čă‚’ć†äœœæˆă—ăŸă—ă‚‡ă†ă€‚ +`my-nginx`ă‚”ăƒŒăƒ“ă‚čた`Type`を`NodePort`から`LoadBalancer`ă«ć€‰æ›Žă™ă‚‹ă ă‘ă§ă™: + +```shell +kubectl edit svc my-nginx +kubectl get svc my-nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +``` +``` +curl https:// -k +... +Welcome to nginx! +``` + +`EXTERNAL-IP`戗ぼIPケドレă‚čは、パブăƒȘăƒƒă‚Żă‚€ăƒłă‚żăƒŒăƒăƒƒăƒˆă§ćˆ©ç”šćŻèƒœăȘもぼです。 +`CLUSTER-IP`ăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒ/ăƒ—ăƒ©ă‚€ăƒ™ăƒŒăƒˆă‚Żăƒ©ă‚Šăƒ‰ăƒăƒƒăƒˆăƒŻăƒŒă‚Żć†…ă§ăźăżäœżç”šă§ăăŸă™ă€‚ + +AWSでは、type `LoadBalancer`はIPではăȘく(長い)ホă‚čăƒˆćă‚’äœżç”šă™ă‚‹ELBăŒäœœæˆă•ă‚ŒăŸă™ă€‚ +ćźŸéš›ă€æš™æș–た`kubectl get svc`たć‡șćŠ›ă«ćŽăŸă‚‹ă«ăŻé•·ă™ăŽă‚‹ăźă§ă€ăă‚Œă‚’çąșèȘă™ă‚‹ă«ăŻ`kubectl describe service my-nginx`ă‚’ćźŸèĄŒă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +æŹĄăźă‚ˆă†ăȘă‚‚ăźăŒèĄšç€șă•ă‚ŒăŸă™: + +```shell +kubectl describe service my-nginx +... +LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com +... +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +KubernetesăŻă€è€‡æ•°ăźă‚Żăƒ©ă‚čă‚żăƒŒăŠă‚ˆăłă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă«ăŸăŸăŒă‚‹ăƒ•ă‚§ăƒ‡ăƒŹăƒŒă‚·ăƒ§ăƒłă‚”ăƒŒăƒ“ă‚čă‚‚ă‚”ăƒăƒŒăƒˆă—ă€ćŻç”šæ€§ăźć‘äžŠă€ăƒ•ă‚©ăƒŒăƒ«ăƒˆăƒˆăƒŹăƒ©ăƒłă‚čăźć‘äžŠă€ă‚”ăƒŒăƒ“ă‚čたă‚čă‚±ăƒŒăƒ©ăƒ“ăƒȘăƒ†ă‚Łăźć‘äžŠă‚’ćźŸçŸă—ăŸă™ă€‚ +è©łçŽ°ă«ă€ă„ăŠăŻ[ăƒ•ă‚§ăƒ‡ăƒŹăƒŒă‚·ăƒ§ăƒłă‚”ăƒŒăƒ“ă‚čăƒŠăƒŒă‚¶ăƒŒă‚Źă‚€ăƒ‰](/docs/concepts/cluster-administration/federation-service-discovery/)を揂照しどください。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md new file mode 100644 index 0000000000..d71b87f3e2 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -0,0 +1,403 @@ +--- +title: Ingress +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +{{< feature-state for_k8s_version="v1.1" state="beta" >}} +{{< glossary_definition term_id="ingress" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + +## 甹èȘž + +ăŸăšă‚ă‹ă‚Šă‚„ă™ăă™ă‚‹ăŸă‚ă«ă€ă“ăźă‚Źă‚€ăƒ‰ă§ăŻæŹĄăźç”šèȘžă‚’ćźšçŸ©ă—ăŸă™ă€‚ + +- ăƒŽăƒŒăƒ‰: Kubernetesć†…ăźăƒŻăƒŒă‚«ăƒŒăƒžă‚·ăƒłă§ă€ă‚Żăƒ©ă‚čă‚żăƒŒăźäž€éƒšă§ă™ă€‚ + +- ă‚Żăƒ©ă‚čă‚żăƒŒ: Kubernetesă«ă‚ˆăŁăŠçźĄç†ă•ă‚ŒăŠă„ă‚‹ă‚łăƒłăƒ†ăƒŠćŒ–ă•ă‚ŒăŸă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă•ă›ă‚‹ăƒŽăƒŒăƒ‰ăźă‚»ăƒƒăƒˆă§ă™ă€‚ă“ăźäŸ‹ă‚„ă€ć€šăăźKubernetesă«ă‚ˆă‚‹ăƒ‡ăƒ—ăƒ­ă‚€ă§ăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźăƒŽăƒŒăƒ‰ăŻăƒ‘ăƒ–ăƒȘăƒƒă‚Żă‚€ăƒłă‚żăƒŒăƒăƒƒăƒˆăšă—ăŠć…Źé–‹ă•ă‚ŒăŠă„ăŸă›ă‚“ă€‚ + +- ă‚šăƒƒă‚žăƒ«ăƒŒă‚żăƒŒ: ă‚Żăƒ©ă‚čă‚żăƒŒă§ăƒ•ă‚Ąă‚€ă‚ąă‚Šă‚©ăƒŒăƒ«ăźăƒăƒȘă‚·ăƒŒă‚’ćŒ·ćˆ¶ă™ă‚‹ăƒ«ăƒŒă‚żăƒŒă§ă™ă€‚ă‚šăƒƒă‚žăƒ«ăƒŒă‚żăƒŒăŻă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă‚„ăƒăƒŒăƒ‰ă‚Šă‚§ă‚ąăźç‰©ç†çš„ăȘ侀郹べしど缡理されたă‚ČăƒŒăƒˆă‚Šă‚§ă‚€ăšăȘă‚ŠăŸă™ă€‚ + +- ă‚Żăƒ©ă‚čă‚żăƒŒăƒăƒƒăƒˆăƒŻăƒŒă‚Ż: ç‰©ç†çš„ăŸăŸăŻè«–ç†çš„ăȘăƒȘăƒłă‚Żăźă‚»ăƒƒăƒˆă§ă€Kubernetesた[ăƒăƒƒăƒˆăƒŻăƒŒă‚Żăƒąăƒ‡ăƒ«](/docs/concepts/cluster-administration/networking/)ă«ă‚ˆăŁăŠă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă§ăźă‚łăƒŸăƒ„ăƒ‹ă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćžă‚‹ă‚‚ăźă§ă™ă€‚ + +- Service: {{< glossary_tooltip text="ăƒ©ăƒ™ăƒ«" term_id="label" >}}ă‚»ăƒŹă‚Żă‚żăƒŒă‚’äœżăŁăŸPodăźă‚»ăƒƒăƒˆă‚’ç‰č漚するKubernetes {{< glossary_tooltip term_id="service" >}}です。ç‰čă«èš€ćŠăŒăȘい限り、ServiceăŻă‚Żăƒ©ă‚čă‚żăƒŒăƒăƒƒăƒˆăƒŻăƒŒă‚Żć†…ă§ăźăżç–Žé€šćŻèƒœăȘä»źæƒłIPă‚’æŒă€ăšæƒłćźšă•ă‚ŒăŸă™ă€‚ + +## IngressăšăŻäœ•ă‹ + +IngressăŻă‚Żăƒ©ă‚čă‚żăƒŒć€–ă‹ă‚‰ă‚Żăƒ©ă‚čă‚żăƒŒć†…{{< link text="Service" url="/docs/concepts/services-networking/service/" >}}ぞたHTTPずHTTPSăźăƒ«ăƒŒăƒˆă‚’ć…Źé–‹ă—ăŸă™ă€‚ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żăźăƒ«ăƒŒăƒ†ă‚Łăƒłă‚°ăŻIngressăƒȘă‚œăƒŒă‚čäžŠă§ćźšçŸ©ă•ă‚Œă‚‹ăƒ«ăƒŒăƒ«ă«ă‚ˆăŁăŠćˆ¶ćŸĄă•ă‚ŒăŸă™ă€‚ + +```none + internet + | + [ Ingress ] + --|-----|-- + [ Services ] +``` + +IngressはServiceă«ćŻŸă—ăŠă€ć€–éƒšç–Žé€šă§ăă‚‹URL、èČ è·ćˆ†æ•Łăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă€SSL/TLSç”‚ç«Żăźæ©Ÿèƒœă‚„ă€ćć‰ăƒ™ăƒŒă‚čăźä»źæƒłăƒ›ă‚čăƒ†ă‚Łăƒłă‚°ă‚’æäŸ›ă™ă‚‹ă‚ˆă†ă«æ§‹æˆă§ăăŸă™ă€‚[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)ăŻé€šćžžăŻăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’äœżç”šă—ăŠIngressăźæ©Ÿèƒœă‚’ćźŸçŸă—ăŸă™ăŒă€ă‚šăƒƒă‚žăƒ«ăƒŒă‚żăƒŒă‚„ă€èżœćŠ ăźăƒ•ăƒ­ăƒłăƒˆă‚šăƒłăƒ‰ă‚’æ§‹æˆă—ăŠăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żăźć‡Šç†ă‚’æ”ŻæŽă™ă‚‹ă“ăšă‚‚ă§ăăŸă™ă€‚ + +IngressăŻä»»æ„ăźăƒăƒŒăƒˆă‚„ăƒ—ăƒ­ăƒˆă‚łăƒ«ă‚’ć…Źé–‹ă—ăŸă›ă‚“ă€‚HTTPやHTTPS仄怖たServiceă‚’ă‚€ăƒłă‚żăƒŒăƒăƒƒăƒˆă«ć…Źé–‹ă™ă‚‹ăšăăŻă€[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)たServiceă‚żă‚€ăƒ—ă‚’äœżç”šă™ă‚‹ă“ăšăŒć€šă„ă§ă™ă€‚ + +## Ingressă‚’äœżç”šă™ă‚‹äžŠă§ăźć‰ææĄä»¶ + +Ingressăźæ©Ÿèƒœă‚’æäŸ›ă™ă‚‹ăŸă‚ă«[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)ă‚’ç”šæ„ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚IngressăƒȘă‚œăƒŒă‚čă‚’äœœæˆă™ă‚‹ăźăżă§ăŻäœ•ăźćŠčæžœă‚‚ă‚ă‚ŠăŸă›ă‚“ă€‚ + +[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)ぼようăȘIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźăƒ‡ăƒ—ăƒ­ă‚€ăŒćż…èŠăȘć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ăƒŠăƒŒă‚¶ăƒŒăŻă„ăă€ă‹ăź[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)ăźäž­ă‹ă‚‰éžæŠžă§ăăŸă™ă€‚ + +ç†æƒłçš„ă«ăŻă€ć…šăŠăźIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻăƒȘファレンă‚čăźä»•æ§˜ă‚’æș€ăŸă™ăčăă§ă™ă€‚ă—ă‹ă—ćźŸéš›ă«ăŻă€ă„ăă€ă‹ăźIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻćŸźćŠ™ă«ç•°ăȘă‚‹ć‹•äœœă‚’ă—ăŸă™ă€‚ + +{{< note >}} +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’çąșèȘă—ăŠă€éžæŠžă™ă‚‹éš›ăźæłšæ„ç‚čă«ă€ă„ăŠç†è§Łă—ăŠăă ă•ă„ă€‚ +{{< /note >}} + +## IngressăƒȘă‚œăƒŒă‚č + +IngressăƒȘă‚œăƒŒă‚čăźæœ€ć°æ§‹æˆăźäŸ‹ăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: test-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - http: + paths: + - path: /testpath + backend: + serviceName: test + servicePort: 80 +``` + +他た慚おたKubernetesăƒȘă‚œăƒŒă‚čăšćŒæ§˜ă«ă€Ingressは`apiVersion`、`kind`や`metadata`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŒćż…èŠă§ă™ă€‚èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ăźćˆ©ç”šă«é–ąă™ă‚‹äž€èˆŹçš„ăȘæƒ…ć ±ăŻă€[ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźăƒ‡ăƒ—ăƒ­ă‚€](/docs/tasks/run-application/run-stateless-application-deployment/)、[ă‚łăƒłăƒ†ăƒŠăƒŒăźèš­ćźš](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[ăƒȘă‚œăƒŒă‚čぼ缡理](/docs/concepts/cluster-administration/manage-deployment/)を揂照しどください。 +Ingressでは、Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«äŸć­˜ă—ăŠă„ă‚‹ă„ăă€ă‹ăźă‚Șăƒ—ă‚·ăƒ§ăƒłăźèš­ćźšă‚’ă™ă‚‹ăŸă‚ă«ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłă‚’äœżă†ă“ăšăŒć€šă„ă§ă™ă€‚ăăźäŸ‹ăšă—ăŠăŻă€[rewrite-targetă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒł](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)ăȘă©ăŒă‚ă‚ŠăŸă™ă€‚ +[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/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ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă«ćŻŸă—ăŠăźăƒ«ăƒŒăƒ«ăźăżă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ + +### Ingressăźăƒ«ăƒŒăƒ« + +搄HTTPăƒ«ăƒŒăƒ«ăŻäž‹èš˜ăźæƒ…ć ±ă‚’ć«ăżăŸă™ă€‚ + +* ă‚Șăƒ—ă‚·ăƒ§ăƒłă§èš­ćźšćŻèƒœăȘホă‚čăƒˆćă€‚äžŠèš˜ăźăƒȘă‚œăƒŒă‚čăźäŸ‹ă§ăŻă€ăƒ›ă‚čăƒˆćăŒæŒ‡ćźšă•ă‚ŒăŠă„ăȘă„ăšă€ăăźăƒ«ăƒŒăƒ«ăŻæŒ‡ćźšă•ă‚ŒăŸIPケドレă‚čă‚’ç”Œç”±ă™ă‚‹ć…šăŠăźă‚€ăƒłăƒă‚Šăƒłăƒ‰HTTPăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă«é©ç”šă•ă‚ŒăŸă™ă€‚ăƒ›ă‚čăƒˆćăŒæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăš(䟋: foo.bar.com)ă€ăăźăƒ«ăƒŒăƒ«ăŻăƒ›ă‚čăƒˆă«ćŻŸă—ăŠé©ç”šă•ă‚ŒăŸă™ă€‚ +* パă‚čたăƒȘă‚čト(䟋: `/testpath`)。搄パă‚čには`serviceName`ず`servicePort`ă§ćźšçŸ©ă•ă‚Œă‚‹ăƒăƒƒă‚Żă‚šăƒłăƒ‰ăŒé–ąé€Łă„ă‘ă‚‰ă‚ŒăŸă™ă€‚ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăŒăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’é–ąé€Łă„ă‘ă‚‰ă‚ŒăŸServiceă«è»ąé€ă™ă‚‹ăŸă‚ă«ă€ć€–éƒšă‹ă‚‰ăă‚‹ăƒȘクスă‚čトぼホă‚čト損べパă‚čăŒæĄä»¶ăšäž€è‡Žă•ă›ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +* [Serviceăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](/docs/concepts/services-networking/service/)ă«æ›žă‹ă‚ŒăŠă„ă‚‹ă‚ˆă†ă«ă€ăƒăƒƒă‚Żă‚šăƒłăƒ‰ăŻServiceăšăƒăƒŒăƒˆćăźç”„ăżćˆă‚ă›ăšăȘă‚ŠăŸă™ă€‚Ingressă§èš­ćźšă•ă‚ŒăŸăƒ›ă‚čト損べパă‚čăźăƒ«ăƒŒăƒ«ă«äž€è‡Žă™ă‚‹HTTP(ずHTTPS)たăƒȘクスă‚čトは、ăƒȘă‚čăƒˆć†…ăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ă«ćŻŸă—ăŠé€äżĄă•ă‚ŒăŸă™ă€‚ + +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă§ăŻă€ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ăŒèš­ćźšă•ă‚ŒăŠă„ă‚‹ă“ăšăŒă‚ă‚ŠăŸă™ă€‚ă“ă‚ŒăŻSpecć†…ă§æŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăƒ‘ă‚čă«äž€è‡Žă—ăȘいようăȘăƒȘクスă‚čトぼためぼバックスンドです。 + +### ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ + +ăƒ«ăƒŒăƒ«ăŒèš­ćźšă•ă‚ŒăŠă„ăȘいIngressăŻă€ć…šăŠăźăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ă«è»ąé€ă—ăŸă™ă€‚ă“ăźăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ăŻă€[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)たă‚Șăƒ—ă‚·ăƒ§ăƒłèš­ćźšă§ă‚ă‚Šă€IngressăƒȘă‚œăƒŒă‚čă§ăŻæŒ‡ćźšă•ă‚ŒăŠă„ăŸă›ă‚“ă€‚ + +Ingressă‚ȘブゾェクトでHTTPăƒȘクスă‚čトが1ă€ă‚‚ăƒ›ă‚čト損べパă‚čăźæĄä»¶ă«äž€è‡Žă—ăȘă„æ™‚ă€ăăźăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚ŻăŻăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰ă«è»ąé€ă•ă‚ŒăŸă™ă€‚ + +## Ingressăźă‚żă‚€ăƒ— + +### 捘侀ServiceたIngress +ăƒŠăƒŒă‚¶ăƒŒăŻć˜äž€ăźServiceを慬開できるべいう、Kubernetesăźă‚łăƒłă‚»ăƒ—ăƒˆăŒă‚ă‚ŠăŸă™([Ingressăźä»Łæ›żæĄˆ](#alternatives)を揂照しどください)。 +ăŸăŸă€Ingressă§ă“ă‚Œă‚’ćźŸçŸă§ăăŸă™ă€‚ăă‚ŒăŻăƒ«ăƒŒăƒ«ă‚’èš­ćźšă›ăšă«*ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒăƒƒă‚Żă‚šăƒłăƒ‰* ă‚’æŒ‡ćźšă™ă‚‹ă“ăšă«ă‚ˆă‚ŠćŻèƒœă§ă™ă€‚ + +{{< codenew file="service/networking/ingress.yaml" >}} + +`kubectl apply -f`ă‚’ćźŸèĄŒă—ăŠIngressă‚’äœœæˆă—ă€ăăźäœœæˆă—ăŸIngressăźçŠ¶æ…‹ă‚’çąșèȘă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + +```shell +kubectl get ingress test-ingress +``` + +``` +NAME HOSTS ADDRESS PORTS AGE +test-ingress * 107.178.254.228 80 59s +``` + +`107.178.254.228`はIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠć‰Čă‚Šćœ“ăŠă‚‰ă‚ŒăŸIPで、こぼIngressă‚’ćˆ©ç”šă™ă‚‹ăŸă‚ăźă‚‚ăźă§ă™ă€‚ + +{{< note >}} +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăŒIPケドレă‚čć‰Čă‚Šćœ“ăŠă‚‹ăźă«1、2ćˆ†ă»ă©ă‹ă‹ă‚ŠăŸă™ă€‚ă“ăźé–“ă€ADDRESSăźæƒ…ć ±ăŻ``ずăȘっどいるぼをçąșèȘă§ăăŸă™ă€‚ +{{< /note >}} + +### ăƒȘクスă‚čăƒˆăźă‚·ăƒłăƒ—ăƒ«ăȘăƒ«ăƒŒăƒ†ă‚Łăƒłă‚° + +ăƒ•ă‚Ąăƒłă‚ąă‚Šăƒˆèš­ćźšă§ăŻć˜äž€ăźIPケドレă‚čăźăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ă€ăƒȘクスă‚čトされたHTTP URIにćŸșいいお1぀仄䞊たServiceă«è»ąé€ă—ăŸă™ă€‚Ingressă«ă‚ˆăŁăŠă€ăƒŠăƒŒă‚¶ăƒŒăŻăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźæ•°ă‚’ć°‘ăȘăă§ăăŸă™ă€‚äŸ‹ăˆă°ă€äž‹èš˜ăźă‚ˆă†ă«èš­ćźšă—ăŸă™ă€‚ + +```none +foo.bar.com -> 178.91.123.132 -> / foo service1:4200 + / bar service2:8080 +``` + +Ingressă‚’äž‹èš˜ăźă‚ˆă†ă«èš­ćźšă—ăŸă™ă€‚ + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: simple-fanout-example + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - host: foo.bar.com + http: + paths: + - path: /foo + backend: + serviceName: service1 + servicePort: 4200 + - path: /bar + backend: + serviceName: service2 + servicePort: 8080 +``` + +Ingressを`kubectl apply -f`ă«ă‚ˆăŁăŠäœœæˆă—ăŸăšă: + +```shell +kubectl describe ingress simple-fanout-example +``` + +``` +Name: simple-fanout-example +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:4200 (10.8.0.90:4200) + /bar service2:8080 (10.8.0.91:8080) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 22s loadbalancer-controller default/test +``` + +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻService(`service1`、`service2`)が歘朹する限り、IngressăźæĄä»¶ă‚’æș€ăŸă™ćźŸèŁ…ć›șæœ‰ăźăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’æ§‹çŻ‰ă—ăŸă™ă€‚ +æ§‹çŻ‰ăŒćźŒäș†ă™ă‚‹ăšă€ADDRESSăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźă‚ąăƒ‰ăƒŹă‚čをçąșèȘă§ăăŸă™ă€‚ + +{{< note >}} +ăƒŠăƒŒă‚¶ăƒŒăŒäœżç”šă—ăŠă„ă‚‹[Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)ă«äŸć­˜ă—ăŸă™ăŒă€ăƒŠăƒŒă‚¶ăƒŒăŻdefault-http-backend[Service](/docs/concepts/services-networking/service/)ăźäœœæˆăŒćż…èŠăȘć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ +{{< /note >}} + +### ćć‰ăƒ™ăƒŒă‚čăźä»źæƒłăƒ›ă‚čティング + +ćć‰ăƒ™ăƒŒă‚čăźä»źæƒłăƒ›ă‚čトは、HTTPăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ćŒäž€ăźIPケドレă‚čăźè€‡æ•°ăźăƒ›ă‚čăƒˆćă«è»ąé€ă™ă‚‹ă“ăšă‚’ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ + +```none +foo.bar.com --| |-> foo.bar.com service1:80 + | 178.91.123.132 | +bar.foo.com --| |-> bar.foo.com service2:80 +``` + +äž‹èš˜ăźIngressèš­ćźšăŻă€ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă«ćŻŸă—ăŠă€[Hostăƒ˜ăƒƒăƒ€ăƒŒ](https://tools.ietf.org/html/rfc7230#section-5.4)にćŸșいいおăƒȘクスă‚čăƒˆă‚’è»ąé€ă™ă‚‹ă‚ˆă†ă«æŒ‡ç€șするもぼです。 + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + - host: bar.foo.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 +``` + +rules項盼でぼホă‚čăƒˆăźèš­ćźšăŒăȘいIngressă‚’äœœæˆă™ă‚‹ăšă€Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźIPケドレă‚čă«ćŻŸă™ă‚‹webăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚ŻăŻă€èŠæ±‚ă•ă‚ŒăŠă„ă‚‹ćć‰ăƒ™ăƒŒă‚čăźä»źæƒłăƒ›ă‚čトăȘă—ă«ăƒžăƒƒăƒă•ă›ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + +äŸ‹ăˆă°ă€äž‹èš˜ăźIngressăƒȘă‚œăƒŒă‚čは`first.bar.com`ă«ćŻŸă™ă‚‹ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’`service1`ま、`second.foo.com`ă«ćŻŸă™ă‚‹ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’`service2`ま、ăƒȘクスă‚čăƒˆă«ăŠă„ăŠăƒ›ă‚čăƒˆćăŒæŒ‡ćźšă•ă‚ŒăŠă„ăȘい(ăƒȘクスă‚čăƒˆăƒ˜ăƒƒăƒ€ăƒŒăŒăȘă„ă“ăšă‚’æ„ć‘łă—ăŸă™)ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚ŻăŻ`service3`ăžè»ąé€ă—ăŸă™ă€‚ + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: first.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + - host: second.foo.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 + - http: + paths: + - backend: + serviceName: service3 + servicePort: 80 +``` + +### TLS + +TLSăźç§˜ćŻ†é”ăšèšŒæ˜Žæ›žă‚’ć«ă‚“ă {{< glossary_tooltip term_id="secret" >}}ă‚’æŒ‡ćźšă™ă‚‹ă“ăšă«ă‚ˆă‚Šă€Ingressă‚’ă‚»ă‚­ăƒ„ă‚ąă«ă§ăăŸă™ă€‚çŸćœšIngressは捘侀ぼTLSăƒăƒŒăƒˆă§ă‚ă‚‹443ç•ȘăƒăƒŒăƒˆăźăżă‚”ăƒăƒŒăƒˆă—ă€TLSç”‚ç«Żă‚’èĄŒă†ă“ăšă‚’æƒłćźšă—ăŠă„ăŸă™ă€‚IngressたTLSèš­ćźšăźă‚»ă‚Żă‚·ăƒ§ăƒłă§ç•°ăȘるホă‚čăƒˆă‚’æŒ‡ćźšă™ă‚‹ăšă€ăă‚Œă‚‰ăźăƒ›ă‚čトはSNI TLSスクă‚čăƒ†ăƒłă‚·ăƒ§ăƒł(Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒSNIă‚’ă‚”ăƒăƒŒăƒˆă—ăŠă„ă‚‹ć Žćˆ)ă‚’ä»‹ă—ăŠæŒ‡ćźšă•ă‚ŒăŸăƒ›ă‚čăƒˆćă«ćŻŸă—ă€ćŒă˜ăƒăƒŒăƒˆäžŠă§ć€šé‡ćŒ–ă•ă‚ŒăŸă™ă€‚TLSたSecretは`tls.crt`ず`tls.key`ăšă„ă†ă‚­ăƒŒă‚’ć«ă‚€ćż…èŠăŒă‚ă‚Šă€TLSă‚’äœżç”šă™ă‚‹ăŸă‚ăźèšŒæ˜Žæ›žăšç§˜ćŻ†é”ă‚’ć«ă‚€ć€€ăšăȘă‚ŠăŸă™ă€‚äž‹èš˜ăŒäŸ‹ăšăȘă‚ŠăŸă™ă€‚ + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: testsecret-tls + namespace: default +data: + tls.crt: base64 encoded cert + tls.key: base64 encoded key +type: kubernetes.io/tls +``` + +IngressでこぼSecretă‚’ć‚ç…§ă™ă‚‹ăšă€ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăšăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒé–“ăźé€šäżĄă«TLSă‚’äœżç”šă™ă‚‹ă‚ˆă†Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«æŒ‡ç€șするこずにăȘă‚ŠăŸă™ă€‚äœœæˆă—ăŸTLS Secretは、`sslexample.foo.com`ăźćźŒć…šäżźéŁŸăƒ‰ăƒĄă‚€ăƒłć(FQDN)ăšă‚‚ć‘Œă°ă‚Œă‚‹ć…±é€šć(CN)ă‚’ć«ă‚€èšŒæ˜Žæ›žă‹ă‚‰äœœæˆă—ăŸă‚‚ăźă§ă‚ă‚‹ă“ăšă‚’çąșèȘă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: tls-example-ingress +spec: + tls: + - hosts: + - sslexample.foo.com + secretName: testsecret-tls + rules: + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 +``` + +{{< note >}} +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠă€ă‚”ăƒăƒŒăƒˆă•ă‚Œă‚‹TLSăźæ©Ÿèƒœă«é•ă„ăŒă‚ă‚ŠăŸă™ă€‚ćˆ©ç”šă™ă‚‹ç’°ćąƒă§TLSăŒă©ăźă‚ˆă†ă«ć‹•äœœă™ă‚‹ă‹ă‚’ç†è§Łă™ă‚‹ăŸă‚ă«ă€[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)ă€ä»–ăźăƒ—ăƒ©ăƒƒăƒˆăƒ•ă‚©ăƒŒăƒ ć›șæœ‰ăźIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’çąșèȘă—ăŠăă ă•ă„ă€‚ +{{< /note >}} + +### èČ è·ćˆ†æ•Ł + +Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă€èČ è·ćˆ†æ•Łă‚ąăƒ«ă‚ŽăƒȘă‚șムやバックスンドぼ重みă‚čă‚­ăƒŒăƒ ăȘど、すăčおたIngressă«é©ç”šă•ă‚Œă‚‹ă„ăă€ă‹ăźèČ è·ćˆ†æ•ŁăƒăƒȘă‚·ăƒŒăźèš­ćźšăšăšă‚‚ă«ăƒ–ăƒŒăƒˆă‚čăƒˆăƒ©ăƒƒăƒ—ă•ă‚ŒăŸă™ă€‚ç™șć±•ă—ăŸèČ è·ćˆ†æ•Łăźă‚łăƒłă‚»ăƒ—ăƒˆ(䟋: ă‚»ăƒƒă‚·ăƒ§ăƒłăźæ°žç¶šćŒ–ă€ć‹•çš„é‡ăżä»˜ă‘ăȘど)はIngressă«ă‚ˆăŁăŠă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ăŸă›ă‚“ă€‚ä»Łă‚ă‚Šă«ă€ăă‚Œă‚‰ăźæ©ŸèƒœăŻServiceç”šăźăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’ä»‹ă—ăŠćˆ©ç”šă§ăăŸă™ă€‚ + +Ingressă«ă‚ˆăŁăŠăƒ˜ăƒ«ă‚čăƒă‚§ăƒƒă‚Żăźæ©ŸèƒœăŒç›ŽæŽ„ă«ć…Źé–‹ă•ă‚ŒăŠă„ăȘい栮搈でも、Kubernetesă«ăŠă„ăŠă€ćŒç­‰ăźæ©Ÿèƒœă‚’æäŸ›ă™ă‚‹[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)ぼようăȘă‚łăƒłă‚»ăƒ—ăƒˆăŒć­˜ćœšă™ă‚‹ă“ăšăŻæłšç›źă«ć€€ă—ăŸă™ă€‚ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒă©ăźă‚ˆă†ă«ăƒ˜ăƒ«ă‚čăƒă‚§ăƒƒă‚Żă‚’èĄŒă†ă‹ă«ă€ă„ăŠăŻă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’ć‚ç…§ă—ăŠăă ă•ă„([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 + +## Ingressăźæ›Žæ–° + +ăƒȘă‚œăƒŒă‚čă‚’ç·šé›†ă™ă‚‹ă“ăšă§ă€æ—ąć­˜ăźIngressă«ćŻŸă—ăŠæ–°ă—ă„ăƒ›ă‚čăƒˆă‚’èżœćŠ ă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + +```shell +kubectl describe ingress test +``` + +``` +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:80 (10.8.0.90:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 35s loadbalancer-controller default/test +``` + +```shell +kubectl edit ingress test +``` + +ă“ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă™ă‚‹ăšæ—ąć­˜ăźèš­ćźšă‚’YAMLăƒ•ă‚©ăƒŒăƒžăƒƒăƒˆă§ç·šé›†ă™ă‚‹ă‚šăƒ‡ă‚Łă‚żăƒŒăŒèĄšç€șă•ă‚ŒăŸă™ă€‚æ–°ă—ă„ăƒ›ă‚čăƒˆă‚’èżœćŠ ă™ă‚‹ăŸă‚ă«ă€ăƒȘă‚œăƒŒă‚čă‚’äżźæ­Łă—ăŠăă ă•ă„ă€‚ + +```yaml +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + path: /foo + - host: bar.baz.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 + path: /foo +.. +``` + +ć€‰æ›Žă‚’äżć­˜ă—ăŸćŸŒă€kubectlはAPIă‚”ăƒŒăƒăƒŒć†…ăźăƒȘă‚œăƒŒă‚čă‚’æ›Žæ–°ă—ă€Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ćŻŸă—ăŠăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźć†èš­ćźšă‚’æŒ‡ç€șă—ăŸă™ă€‚ + +ć€‰æ›Žć†…ćźčをçąșèȘă—ăŠăă ă•ă„ă€‚ + +```shell +kubectl describe ingress test +``` + +``` +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:80 (10.8.0.90:80) + bar.baz.com + /foo service2:80 (10.8.0.91:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 45s loadbalancer-controller default/test +``` + +äżźæ­Łă•ă‚ŒăŸIngressたYAMLăƒ•ă‚Ąă‚€ăƒ«ă«ćŻŸă—ăŠ`kubectl replace -f`ă‚’ćźŸèĄŒă™ă‚‹ă“ăšă§ă€ćŒæ§˜ăźç”æžœă‚’ćŸ—ă‚‰ă‚ŒăŸă™ă€‚ + +## ă‚ąăƒ™ă‚€ăƒ©ăƒ“ăƒȘăƒ†ă‚ŁăƒŒă‚ŸăƒŒăƒłă‚’ăŸăŸă„ă éšœćźłă«ă€ă„ăŠ + +éšœćźłăźă‚ă‚‹ăƒ‰ăƒĄă‚€ăƒłă‚’ăŸăŸă„ă§ăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚Żă‚’ćˆ†æ•Łă™ă‚‹æ‰‹æł•ăŻă€ă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă«ă‚ˆăŁăŠç•°ăȘă‚ŠăŸă™ă€‚è©łçŽ°ă«é–ąă—ăŠă€[Ingress ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers)ăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’ć‚ç…§ă—ăŠăă ă•ă„ă€‚è€‡æ•°ăźă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă„ăŠIngressă‚’ăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹æ–čæł•ăźè©łçŽ°ă«é–ąă—ăŠăŻ[Kubernetes Cluster Federationăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](https://github.com/kubernetes-sigs/federation-v2)を揂照しどください。 + +## ć°†æ„èżœćŠ äșˆćźšăźć†…ćźč + +Ingressべ閱連するăƒȘă‚œăƒŒă‚čăźä»ŠćŸŒăźé–‹ç™șに぀いおは[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)ă§èĄŒă‚ă‚ŒăŠă„ă‚‹è­°è«–ă‚’çąșèȘă—ăŠăă ă•ă„ă€‚æ§˜ă€…ăȘIngressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźé–‹ç™șに぀いおは[Ingress ăƒȘポゾトăƒȘăƒŒ](https://github.com/kubernetes/ingress/tree/master)をçąșèȘă—ăŠăă ă•ă„ă€‚ + +## Ingressăźä»Łæ›żæĄˆ {#alternatives} + +IngressăƒȘă‚œăƒŒă‚čă«ç›ŽæŽ„é–ąäžŽă—ăȘă„è€‡æ•°ăźæ–čæł•ă§Serviceă‚’ć…Źé–‹ă§ăăŸă™ă€‚ + +äž‹èš˜ăź2ă€ăźäœżç”šă‚’æ€œèšŽă—ăŠăă ă•ă„ă€‚ +* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) +* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) + +{{% /capture %}} + +{{% capture whatsnext %}} +* [Ingressă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](/docs/concepts/services-networking/ingress-controllers/)に぀いお歊ぶ +* [MinikubeずNGINXă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă§Ingressăźă‚»ăƒƒăƒˆă‚ąăƒƒăƒ—ă‚’èĄŒă†](/docs/tasks/access-application-cluster/ingress-minikube) +{{% /capture %}} diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a7f6447d29..71c8795733 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -134,6 +134,13 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)ă«èš­ ExternalName ServiceăŻă‚»ăƒŹă‚Żă‚żăƒŒăźä»Łă‚ă‚Šă«DNSćă‚’äœżç”šă™ă‚‹ç‰čæźŠăȘă‚±ăƒŒă‚čたServiceです。さらăȘă‚‹æƒ…ć ±ăŻă€ă“ăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆăźćŸŒă§çŽč介する[ExternalName](#externalname)を揂照ください。 +### ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚č +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čは、Endpointsă«ćŻŸă—ăŠă‚ˆă‚Šă‚čă‚±ăƒŒăƒ©ăƒ–ăƒ«ăȘä»Łæ›żæ‰‹æź”ă‚’æäŸ›ă§ăă‚‹APIăƒȘă‚œăƒŒă‚čă§ă™ă€‚æŠ‚ćż”çš„ă«ăŻEndpointsă«éžćžžă«äŒŒăŠă„ăŸă™ăŒă€ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čă‚’äœżç”šă™ă‚‹ăšă€ăƒăƒƒăƒˆăƒŻăƒŒă‚Żă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚’è€‡æ•°ăźăƒȘă‚œăƒŒă‚čă«ćˆ†ć‰Čă§ăăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻă€ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čは、100ć€‹ăźă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă«ćˆ°é”ă™ă‚‹ăšă€Œă„ăŁă±ă„ă§ă‚ă‚‹ă€ăšèŠ‹ăȘă•ă‚Œă€ăăźæ™‚ç‚čă§èżœćŠ ăźă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čăŒäœœæˆă•ă‚Œă€èżœćŠ ăźă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăŒäżć­˜ă•ă‚ŒăŸă™ă€‚ + +ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čは、[ă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ](/docs/concepts/services-networking/endpoint-slices/)ă«ăŠè©łă—ăèȘŹæ˜Žă•ă‚ŒăŠă„ă‚‹èżœćŠ ăźć±žæ€§ăšæ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ + ## ä»źæƒłIPăšă‚”ăƒŒăƒ“ă‚čăƒ—ăƒ­ă‚­ă‚·ăƒŒ {#virtual-ips-and-service-proxies} Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒăźć„Nodeは`kube-proxy`ă‚’çšŒćƒă•ă›ăŠă„ăŸă™ă€‚`kube-proxy`は[`ExternalName`](#externalname)ă‚żă‚€ăƒ—ä»„ć€–ăź`Service`ç”šă«ä»źæƒłIPă‚’ćźŸèŁ…ă™ă‚‹èČŹć‹™ăŒă‚ă‚ŠăŸă™ă€‚ @@ -149,12 +156,6 @@ Serviceă«ăŠă„ăŠăƒ—ăƒ­ă‚­ă‚·ăƒŒă‚’äœżă†ç†ç”±ăŻă„ăă€ă‹ă‚ă‚ŠăŸă™ă€‚ * ă„ăă€ă‹ăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă§ăŻDNSăƒ«ăƒƒă‚Żă‚ąăƒƒăƒ—ă‚’1ćșŠă ă‘èĄŒă„ă€ăăźç”æžœă‚’ç„ĄæœŸé™ă«ă‚­ăƒŁăƒƒă‚·ăƒ„する。 * ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăšăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒăŒé©ćˆ‡ăȘDNSćăźć†è§Łæ±șă‚’èĄŒăŁăŸăšă—ăŠă‚‚ă€DNSăƒŹă‚łăƒŒăƒ‰äžŠăź0ă‚‚ă—ăăŻäœŽă„ć€€ăźTTLがDNSにèČ è·ă‚’ă‹ă‘ă‚‹ă“ăšăŒă‚ă‚Šă€çźĄç†ăŒé›Łă—ă„ă€‚ -### ăƒăƒŒă‚žăƒ§ăƒłäș’換性 - -Kubernetes v1.0から、[user-spaceăƒ—ăƒ­ă‚­ă‚·ăƒŒăƒąăƒŒăƒ‰](#proxy-mode-userspace)ă‚’ćˆ©ç”šă§ăă‚‹ă‚ˆă†ă«ăȘăŁăŠă„ăŸă™ă€‚ -v1.1ではiptablesăƒąăƒŒăƒ‰ă§ăźăƒ—ăƒ­ă‚­ă‚·ăƒŒă‚’èżœćŠ ă—ă€v1.2では、kube-proxyにおいおiptablesăƒąăƒŒăƒ‰ăŒăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăšăȘă‚ŠăŸă—ăŸă€‚ -v1.8では、ipvsăƒ—ăƒ­ă‚­ă‚·ăƒŒăƒąăƒŒăƒ‰ăŒèżœćŠ ă•ă‚ŒăŸă—ăŸă€‚ - ### user-spaceăƒ—ăƒ­ă‚­ă‚·ăƒŒăƒąăƒŒăƒ‰ {#proxy-mode-userspace} ă“ăźăƒąăƒŒăƒ‰ă§ăŻă€kube-proxyはServiceやEndpointă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăźèżœćŠ ăƒ»ć‰Šé™€ă‚’ăƒă‚§ăƒƒă‚Żă™ă‚‹ăŸă‚ă«ă€Kubernetes Masteră‚’ç›ŁèŠ–ă—ăŸă™ă€‚ @@ -389,12 +390,11 @@ spec: port: 80 targetPort: 9376 clusterIP: 10.0.171.239 - loadBalancerIP: 78.11.24.19 type: LoadBalancer status: loadBalancer: ingress: - - ip: 146.148.47.155 + - ip: 192.0.2.127 ``` ć€–éƒšăźăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‹ă‚‰ăźăƒˆăƒ©ăƒ•ă‚Łăƒƒă‚ŻăŻăƒăƒƒă‚Żă‚šăƒłăƒ‰ăźPodă«ç›ŽæŽ„è»ąé€ă•ă‚ŒăŸă™ă€‚ă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒăŻă©ăźă‚ˆă†ă«ăăźăƒȘクスă‚čăƒˆă‚’ăƒăƒ©ăƒłă‚·ăƒłă‚°ă™ă‚‹ă‹ă‚’æ±șă‚ăŸă™ă€‚ @@ -437,9 +437,6 @@ metadata: cloud.google.com/load-balancer-type: "Internal" [...] ``` - -Kubernetes1.7.0から1.7.3たMasteră«ćŻŸă—ăŠăŻă€`cloud.google.com/load-balancer-type: "internal"`ă‚’äœżç”šă—ăŸă™ă€‚ -さらăȘă‚‹æƒ…ć ±ă«ă€ă„ăŠăŻă€[docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)を揂照しどください。 {{% /tab %}} {{% tab name="AWS" %}} ```yaml @@ -481,6 +478,15 @@ metadata: [...] ``` {{% /tab %}} +{{% tab name="Tencent Cloud" %}} +```yaml +[...] +metadata: + annotations: + service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx +[...] +``` +{{% /tab %}} {{< /tabs >}} @@ -630,13 +636,11 @@ AWS侊でぼELB Service甚たスクセă‚čăƒ­ă‚°ă‚’çźĄç†ă™ă‚‹ăŸă‚ă«ăŻă„ă # ELBă«èżœćŠ ă•ă‚Œă‚‹äșˆćźšăźă‚»ă‚­ăƒ„ăƒȘăƒ†ă‚ŁăƒŒă‚°ăƒ«ăƒŒăƒ—ăźăƒȘă‚čト ``` -#### AWSでたNetwork Load Balancerăźă‚”ăƒăƒŒăƒˆ [α版] {#aws-nlb-support} +#### AWSでたNetwork Load Balancerăźă‚”ăƒăƒŒăƒˆ {#aws-nlb-support} -{{< warning >}} -ă“ă‚ŒăŻÎ±ç‰ˆăźæ©Ÿèƒœă§ă€ăƒ—ăƒ­ăƒ€ă‚Żă‚·ăƒ§ăƒłç’°ćąƒă§ăźă‚Żăƒ©ă‚čă‚żăƒŒă§ăźäœżç”šăŻăŸă æŽšć„šă—ăŸă›ă‚“ă€‚ -{{< /warning >}} +{{< feature-state for_k8s_version="v1.15" state="beta" >}} -Kubernetes v1.9.0から、ServiceずAWS Network Load Balancer(NLB)ă‚’ç”„ăżćˆă‚ă›ă‚‹ă“ăšăŒă§ăăŸă™ă€‚AWSă§ăźăƒăƒƒăƒˆăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’äœżç”šă™ă‚‹ăŸă‚ă«ăŻă€`service.beta.kubernetes.io/aws-load-balancer-type`ăšă„ă†ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłăźć€€ă‚’`nlb`ă«èš­ćźšă—ăŠăă ă•ă„ă€‚ +AWSでNetwork Load Balanceră‚’äœżç”šă™ă‚‹ă«ăŻă€ć€€ă‚’`nlb`ă«èš­ćźšă—ăŠă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒł`service.beta.kubernetes.io/aws-load-balancer-type`ă‚’ä»˜äžŽă—ăŸă™ă€‚ ```yaml metadata: @@ -681,6 +685,38 @@ spec: {{< /note >}} +#### Tencent Kubernetes EngineTKEïŒ‰ă«ăŠă‘ă‚‹ăăźä»–ăźCLBă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒł + +仄䞋にç€șă™ă‚ˆă†ă«ă€TKEでCloud Load Balanceră‚’çźĄç†ă™ă‚‹ăŸă‚ăźăăźä»–ăźă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłăŒă‚ă‚ŠăŸă™ă€‚ + +```yaml + metadata: + name: my-service + annotations: + # æŒ‡ćźšă—ăŸăƒŽăƒŒăƒ‰ă§ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’ăƒă‚€ăƒłăƒ‰ă—ăŸă™ + service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2) + # æ—ąć­˜ăźăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźID + service.kubernetes.io/tke-existed-lbidlb-6swtxxxx + + # ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒ(LB)たカă‚čă‚żăƒ ăƒ‘ăƒ©ăƒĄăƒŒă‚żăƒŒăŻă€LBă‚żă‚€ăƒ—ăźć€‰æ›Žă‚’ăŸă ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă›ă‚“ + service.kubernetes.io/service.extensiveParameters: "" + + # LBăƒȘă‚čăƒŠăƒŒăźă‚«ă‚čă‚żăƒ ăƒ‘ăƒ©ăƒĄăƒŒă‚żăƒŒ + service.kubernetes.io/service.listenerParameters: "" + + # ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźă‚żă‚€ăƒ—ă‚’æŒ‡ćźšă—ăŸă™ + # 有ćŠčăȘ怀: classic(Classic Cloud Load Balancer)ăŸăŸăŻapplication(Application Cloud Load Balancer) + service.kubernetes.io/loadbalance-type: xxxxx + # パブăƒȘăƒƒă‚ŻăƒăƒƒăƒˆăƒŻăƒŒă‚ŻćžŻćŸŸćč…たèȘČ金æ–čæł•ă‚’æŒ‡ćźšă—ăŸă™ + # 有ćŠčăȘ怀: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth) + service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx + # 澯柟ćč…ăźć€€ă‚’æŒ‡ćźšă—ăŸă™(怀た範ć›Č[1-2000] Mbps)。 + service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" + # ă“ăźæłšé‡ˆăŒèš­ćźšă•ă‚ŒăŠă„ă‚‹ć Žćˆă€ăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăŻăƒăƒƒăƒ‰ăŒćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ăƒŽăƒŒăƒ‰ăźăżă‚’ç™»éŒČă—ăŸă™ + # そうでăȘい栮搈、すăčăŠăźăƒŽăƒŒăƒ‰ăŒç™»éŒČă•ă‚ŒăŸă™ + service.kubernetes.io/local-svc-only-bind-node-with-pod: true +``` + ### ExternalName ă‚żă‚€ăƒ— {#externalname} ExternalNameă‚żă‚€ăƒ—ăźServiceは、ServiceをDNS損べマッピングし、`my-service`や`cassandra`べいうようăȘćŸ“æ„ăźăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒăšăŻăƒžăƒƒăƒ”ăƒłă‚°ă—ăŸă›ă‚“ă€‚ @@ -708,6 +744,12 @@ IPケドレă‚čă‚’ăƒăƒŒăƒ‰ă‚łăƒŒăƒ‰ă™ă‚‹ć Žćˆă€[Headless Service](#headless-s `my-service`ぞたスクセă‚čは、他たServiceべ搌じæ–čæł•ă§ă™ăŒă€ć†æŽ„ç¶šă™ă‚‹éš›ăŻăƒ—ăƒ­ă‚­ă‚·ăƒŒă‚„è»ąé€ă‚’ä»‹ă—ăŠèĄŒă†ă‚ˆă‚Šă‚‚ă€DNSăƒŹăƒ™ăƒ«ă§èĄŒă‚ă‚Œă‚‹ă“ăšăŒæ±ș柚的に異ăȘるç‚čずăȘă‚ŠăŸă™ă€‚ ćŸŒă«ăƒŠăƒŒă‚¶ăƒŒăŒäœżç”šă—ăŠă„ă‚‹ăƒ‡ăƒŒă‚żăƒ™ăƒŒă‚čă‚’ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă«ç§»èĄŒă™ă‚‹ă“ăšă«ăȘăŁăŸćŸŒăŻă€Podă‚’è”·ć‹•ă•ă›ă€é©ćˆ‡ăȘăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒă‚„Endpointă‚’èżœćŠ ă—ă€Serviceた`type`ă‚’ć€‰æ›Žă—ăŸă™ă€‚ +{{< warning >}} +HTTPやHTTPSăȘă©ăźäž€èˆŹçš„ăȘăƒ—ăƒ­ăƒˆă‚łăƒ«ă§ExternalNameă‚’äœżç”šă™ă‚‹éš›ă«ć•éĄŒăŒç™șç”Ÿă™ă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ExternalNameă‚’äœżç”šă™ă‚‹ć Žćˆă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăŒäœżç”šă™ă‚‹ăƒ›ă‚čト損は、ExternalNameが揂照する損才べは異ăȘă‚ŠăŸă™ă€‚ + +ホă‚čăƒˆćă‚’äœżç”šă™ă‚‹ăƒ—ăƒ­ăƒˆă‚łăƒ«ăźć Žćˆă€ă“ăźé•ă„ă«ă‚ˆă‚Šă‚šăƒ©ăƒŒăŸăŸăŻäșˆæœŸă—ăȘい濜答がç™șç”Ÿă™ă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚HTTPăƒȘクスă‚čăƒˆă«ăŻă€ă‚ȘăƒȘă‚žăƒłă‚”ăƒŒăƒăƒŒăŒèȘè­˜ă—ăȘい`Host:`ăƒ˜ăƒƒăƒ€ăƒŒăŒă‚ă‚ŠăŸă™ă€‚TLSă‚”ăƒŒăƒăƒŒăŻă€ă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăŒæŽ„ç¶šă—ăŸăƒ›ă‚čăƒˆćă«äž€è‡Žă™ă‚‹èšŒæ˜Žæ›žă‚’æäŸ›ă§ăăŸă›ă‚“ă€‚ +{{< /warning >}} + {{< note >}} ă“ăźă‚»ă‚Żă‚·ăƒ§ăƒłăŻă€[Alen Komljen](https://akomljen.com/)ă«ă‚ˆă‚‹[Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/)べいうブログポă‚čăƒˆă‚’ć‚è€ƒă«ă—ăŠă„ăŸă™ă€‚ @@ -905,5 +947,6 @@ Kubernetesăƒ—ăƒ­ă‚žă‚§ă‚ŻăƒˆăŻă€çŸćœšćˆ©ç”šćŻèƒœăȘClusterIP、NodePortやLo * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を揂照しどください。 * [Ingress](/docs/concepts/services-networking/ingress/)を揂照しどください。 +* [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)を揂照しどください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/storage/_index.md b/content/ja/docs/concepts/storage/_index.md index 7e0dd19b12..4b70c7d04f 100755 --- a/content/ja/docs/concepts/storage/_index.md +++ b/content/ja/docs/concepts/storage/_index.md @@ -1,5 +1,5 @@ --- -title: "Storage" +title: "ă‚čăƒˆăƒŹăƒŒă‚ž" weight: 70 --- diff --git a/content/ja/docs/concepts/workloads/_index.md b/content/ja/docs/concepts/workloads/_index.md index ca394ebd00..41bb9d33d2 100644 --- a/content/ja/docs/concepts/workloads/_index.md +++ b/content/ja/docs/concepts/workloads/_index.md @@ -1,5 +1,5 @@ --- -title: "Workloads" +title: "ăƒŻăƒŒă‚Żăƒ­ăƒŒăƒ‰" weight: 50 --- diff --git a/content/ja/docs/concepts/workloads/controllers/_index.md b/content/ja/docs/concepts/workloads/controllers/_index.md index 6aaa7405b5..65c91d6280 100644 --- a/content/ja/docs/concepts/workloads/controllers/_index.md +++ b/content/ja/docs/concepts/workloads/controllers/_index.md @@ -1,5 +1,4 @@ --- -title: "Controllers" +title: "ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ" weight: 20 --- - diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..1d465cb70d --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,999 @@ +--- +title: Deployment +feature: + title: è‡Șć‹•ćŒ–ă•ă‚ŒăŸăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăšăƒ­ăƒŒăƒ«ăƒăƒƒă‚Ż + description: > + KubernetesはケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„èš­ćźšăžăźć€‰æ›Žă‚’æź”éšŽçš„ă«èĄŒă„ă€ă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźçŠ¶æ…‹ă‚’ç›ŁèŠ–ă—ăȘăŒă‚‰ă€ć…šăŠăźă‚€ăƒłă‚čタンă‚čăŒćŒæ™‚ćœæ­ąă—ăȘă„ă‚ˆă†ă«ă—ăŸă™ă€‚æ›Žæ–°ă«ć•éĄŒăŒè”·ăăŸăšăă€KubernetesăŻć€‰æ›Žăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă‚’èĄŒă„ăŸă™ă€‚é€ČćŒ–ă‚’ç¶šă‘ă‚‹Deploymnetた゚コシă‚čăƒ†ăƒ ă‚’æŽ»ç”šă—ăŠăă ă•ă„ă€‚ + +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +_Deployment_ ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻ[Pod](/docs/concepts/workloads/pods/pod/)ず[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)ăźćźŁèš€çš„ăȘă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆæ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ + +ăƒŠăƒŒă‚¶ăƒŒăŻDeploymentにおいお_ç†æƒłçš„ăȘ状態_ ă‚’ćźšçŸ©ă—ă€Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻæŒ‡ćźšă•ă‚ŒăŸé »ćșŠă§çŸćœšăźçŠ¶æ…‹ă‚’ç†æƒłçš„ăȘçŠ¶æ…‹ă«ć€‰æ›Žă•ă›ăŸă™ă€‚ăƒŠăƒŒă‚¶ăƒŒăŻDeploymentă‚’ćźšçŸ©ă—ăŠă€æ–°ă—ă„ReplicaSetă‚’äœœæˆă—ăŸă‚Šă€æ—ąć­˜ăźDeploymentă‚’ć‰Šé™€ă—ăŠæ–°ă—ă„Deploymentで慹どぼăƒȘă‚œăƒŒă‚čă‚’é©ç”šă§ăăŸă™ă€‚ + +{{< note >}} +Deploymentă«ă‚ˆăŁăŠäœœæˆă•ă‚ŒăŸReplicaSetを缡理しăȘă„ă§ăă ă•ă„ă€‚ăƒŠăƒŒă‚¶ăƒŒăźăƒŠăƒŒă‚čă‚±ăƒŒă‚čăŒäž‹èš˜ăźé …ç›źă‚’ă‚«ăƒăƒŒă§ăăŠă„ăȘă„ć ŽćˆăŻăƒĄă‚€ăƒłăźKubernetesăƒȘポゾトăƒȘăƒŒă«ă‚€ă‚·ăƒ„ăƒŒă‚’äœœæˆă™ă‚‹ă“ăšă‚’æ€œèšŽă—ăŠăă ă•ă„ă€‚ +{{< /note >}} + +{{% /capture %}} + + +{{% capture body %}} + +## ăƒŠăƒŒă‚čă‚±ăƒŒă‚č + +äž‹èš˜ăźé …ç›źăŻDeploymentぼ慾枋的ăȘăƒŠăƒŒă‚čă‚±ăƒŒă‚čです。 + +* ReplicaSetă‚’ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă™ă‚‹ăŸă‚ă«[Deploymentăźäœœæˆ](#creating-a-deployment)ă‚’èĄŒă†: ReplicaSetăŻăƒăƒƒă‚Żă‚°ăƒ©ă‚Šăƒłăƒ‰ă§Podă‚’äœœæˆă—ăŸă™ă€‚PodăźäœœæˆăŒćźŒäș†ă—ăŸă‹ă©ă†ă‹ăŻă€ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŠăă ă•ă„ă€‚ +* DeploymentたPodTemplateSpecă‚’æ›Žæ–°ă™ă‚‹ă“ăšă«ă‚ˆă‚Š[Podăźæ–°ă—ă„çŠ¶æ…‹ă‚’ćźŁèš€ă™ă‚‹](#updating-a-deployment): æ–°ă—ă„ReplicaSetăŒäœœæˆă•ă‚Œă€DeploymentăŻæŒ‡ćźšă•ă‚ŒăŸé »ćșŠă§ć€ă„ReplicaSetă‹ă‚‰æ–°ă—ă„ReplicaSetぞたPodăźç§»èĄŒă‚’çźĄç†ă—ăŸă™ă€‚æ–°ă—ă„ReplicaSetはDeploymentたăƒȘăƒ“ă‚žăƒ§ăƒłă‚’æ›Žæ–°ă—ăŸă™ă€‚ +* DeploymentăźçŸćœšăźçŠ¶æ…‹ăŒäžćź‰ćźšăȘ栮搈、[Deploymentăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Ż](#rolling-back-a-deployment)をする: ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă«ă‚ˆă‚‹ć„æ›Žæ–°äœœæ„­ăŻă€DeploymentたăƒȘăƒ“ă‚žăƒ§ăƒłă‚’æ›Žæ–°ă—ăŸă™ă€‚ +* ă‚ˆă‚Šć€šăăźèČ è·ă‚’ă•ă°ă‘ă‚‹ă‚ˆă†ă«ă€[Deploymentをă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—](#scaling-a-deployment)する +* PodTemplateSpecă«ćŻŸă™ă‚‹è€‡æ•°ăźäżźæ­Łă‚’é©ç”šă™ă‚‹ăŸă‚ă«[Deploymentă‚’ćœæ­ą(Pause)し](#pausing-and-resuming-a-deployment)ă€ăă‚Œă‚’ć†é–‹ă—ăŠæ–°ă—ă„ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’é–‹ć§‹ă™ă‚‹ă€‚ +* ä»ŠćŸŒćż…èŠăšă—ăȘい[ć€ă„ReplicaSetぼクăƒȘăƒŒăƒłă‚ąăƒƒăƒ—](#clean-up-policy) + +## Deploymentăźäœœæˆ {#creating-a-deployment} + +äž‹èš˜ăźć†…ćźčはDeploymentăźäŸ‹ă§ă™ă€‚ă“ă‚ŒăŻ`nginx`PodぼレプăƒȘă‚«ă‚’3ă€æŒă€ReplicaSetă‚’äœœæˆă—ăŸă™ă€‚ + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +ă“ăźäŸ‹ă«ăŠă„ăŠă€ + +* `nginx-deployment`べいう損才ぼDeploymentăŒäœœæˆă•ă‚Œă€`.metadata.name`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ćć‰ă‚’æŒ‡ćźšă—ăŸă™ă€‚ +* Deploymentは3ă€ăźăƒŹăƒ—ăƒȘă‚«Podă‚’äœœæˆă—ă€`replicas`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă«ă‚ˆăŁăŠăƒŹăƒ—ăƒȘă‚«æ•°ă‚’æŒ‡ćźšă—ăŸă™ă€‚ +* `selector`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŻă€Deploymentが缡理するPodăźăƒ©ăƒ™ăƒ«ă‚’ćźšçŸ©ă—ăŸă™ă€‚ă“ăźă‚±ăƒŒă‚čă«ăŠă„ăŠă€ăƒŠăƒŒă‚¶ăƒŒăŻPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă«ăŠćźšçŸ©ă•ă‚ŒăŸăƒ©ăƒ™ăƒ«(`app: nginx`)ă‚’éžæŠžă—ăŸă™ă€‚ă—ă‹ă—ă€PodTemplateè‡Șäœ“ăŒăăźăƒ«ăƒŒăƒ«ă‚’æș€ăŸă™é™ă‚Šă€ă•ă‚‰ă«æŽ—ç·Žă•ă‚ŒăŸæ–čæł•ă§ă‚»ăƒŹă‚Żă‚żăƒŒă‚’æŒ‡ćźšă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + {{< note >}} + `matchLabels`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŻă€ă‚­ăƒŒăšăƒăƒȘăƒ„ăƒŒăźăƒšă‚ąăźăƒžăƒƒăƒ—ăšăȘă‚ŠăŸă™ă€‚`matchLabels`ăƒžăƒƒăƒ—ă«ăŠă„ăŠă€{key, value}べいうペケは、keyăšă„ă†ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźć€€ăŒ"key"ă§ă€ăăźæŒ”çź—ć­ăŒ"In"ă§ă€ć€€ăźé…ćˆ—ăŒ"value"ăźăżć«ă‚€ă‚ˆă†ăȘ`matchExpressions`ăźèŠçŽ ăšç­‰ă—ă„ă§ă™ă€‚ + `matchLabels`ず`matchExpressions`た䞥æ–čăŒèš­ćźšă•ă‚ŒăŸć Žćˆă€æĄä»¶ă«äž€è‡Žă™ă‚‹ă«ăŻäžĄæ–čべもæș€ăŸă™ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ + {{< /note >}} +* `template`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŻă€äž‹èš˜ăźă‚”ăƒ–ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’æŒăĄăŸă™ă€‚: + * Podは`labels`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă«ă‚ˆăŁăŠæŒ‡ćźšă•ă‚ŒăŸ`app: nginx`ăšă„ă†ăƒ©ăƒ™ăƒ«ăŒă€ă‘ă‚‰ă‚Œă‚‹ + * PodTemplateăźä»•æ§˜ă‚‚ă—ăăŻă€`.template.spec`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŻă€ă“ăźPodは`nginx`ăšă„ă†ćć‰ăźă‚łăƒłăƒ†ăƒŠăƒŒă‚’1ă€çšŒćƒă•ă›ă€ăă‚ŒăŻ`nginx`べいうさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`ăźăƒăƒŒă‚žăƒ§ăƒł1.7.9ă‚’äœżă†ă“ăšă‚’ç€șă—ăŸă™ + * 1ă€ăźă‚łăƒłăƒ†ăƒŠă‚’äœœæˆă—ă€`name`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’äœżăŁăŠ`nginx`ăšă„ă†ćć‰ă‚’ă€ă‘ăŸă™ + + äžŠèš˜ăźDeploymentă‚’äœœæˆă™ă‚‹ăŸă‚ă«ă€ä»„äž‹ă«ç€șすă‚čăƒ†ăƒƒăƒ—ă«ă—ăŸăŒăŁăŠăă ă•ă„ă€‚ + äœœæˆă‚’ć§‹ă‚ă‚‹ć‰ă«ă€ăƒŠăƒŒă‚¶ăƒŒăźKubernetesă‚Żăƒ©ă‚čă‚żăƒŒăŒçšŒćƒă—ăŠă„ă‚‹ă“ăšă‚’çąșèȘă—ăŠăă ă•ă„ă€‚ + + 1. äž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠDeploymentă‚’äœœæˆă—ăŠăă ă•ă„ă€‚ + + {{< note >}} + ćźŸèĄŒă—ăŸă‚łăƒžăƒłăƒ‰ă‚’`kubernetes.io/change-cause`ăšă„ă†ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłă«èš˜éŒČă™ă‚‹ăŸă‚ă«`--record`ăƒ•ăƒ©ă‚°ă‚’æŒ‡ćźšă§ăăŸă™ă€‚ă“ă‚ŒăŻć°†æ„çš„ăȘ敏題ぼèȘżæŸ»ăźăŸă‚ă«æœ‰ćŠčă§ă™ă€‚äŸ‹ăˆă°ă€ć„DeploymentたăƒȘăƒ“ă‚žăƒ§ăƒłă«ăŠă„ăŠćźŸèĄŒă•ă‚ŒăŸă‚łăƒžăƒłăƒ‰ă‚’èŠ‹ă‚‹ăšăă«äŸżćˆ©ă§ă™ă€‚ + {{< /note >}} + + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` + + 2. DeploymentăŒäœœæˆă•ă‚ŒăŸă“ăšă‚’çąșèȘă™ă‚‹ăŸă‚ă«ă€`kubectl get deployment`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚DeploymentăŒăŸă äœœæˆäž­ăźć Žćˆă€ă‚łăƒžăƒłăƒ‰ăźćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 0 0 0 1s + ``` + ăƒŠăƒŒă‚¶ăƒŒăźă‚Żăƒ©ă‚čă‚żăƒŒă«ăŠă„ăŠDeploymentをèȘżæŸ»ă™ă‚‹ăšăă€äž‹èš˜ăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăŒć‡șćŠ›ă•ă‚ŒăŸă™ă€‚ + + * `NAME` ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźDeploymentăźćć‰ă‚’èĄšç€șする + * `DESIRED` ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźç†æƒłçš„ăȘ_replicas_ ăźć€€ă‚’èĄšç€șする: これはDeploymentă‚’äœœæˆă—ăŸăšăă«ćźšçŸ©ă—ăŸă‚‚ăźă§ă€ă“ă‚ŒăŒ_ç†æƒłçš„ăȘ状態_ ăšć‘Œă°ă‚Œă‚‹ă‚‚ăźă§ă™ă€‚ + * `CURRENT` çŸćœšçšŒćƒäž­ăźăƒŹăƒ—ăƒȘă‚«æ•° + * `UP-TO-DATE` ç†æƒłçš„ăȘçŠ¶æ…‹ă«ă™ă‚‹ăŸă‚ă«ă€ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăŒćźŒäș†ă—ăŸăƒŹăƒ—ăƒȘă‚«æ•° + * `AVAILABLE` ăƒŠăƒŒă‚¶ăƒŒăŒćˆ©ç”šćŻèƒœăȘレプăƒȘă‚«æ•° + * `AGE` ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăŒçšŒćƒă—ăŠă‹ă‚‰ăźæ™‚é–“ + + äžŠèš˜ăźyamlăźäŸ‹ă ăšă€`.spec.replicas`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźć€€ă«ă‚ˆă‚‹ăšă€ç†æƒłçš„ăȘレプăƒȘă‚«æ•°ăŻ3です。 + + 3. Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă™ă‚‹ăŸă‚ă«ă€`kubectl rollout status deployment.v1.apps/nginx-deployment`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ă‚łăƒžăƒłăƒ‰ăźćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + + 4. æ•°ç§’ćŸŒă€ć†ćșŠ`kubectl get deployments`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ă‚łăƒžăƒłăƒ‰ăźćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 18s + ``` + Deploymentが3ă€ć…šăŠăźăƒŹăƒ—ăƒȘă‚«ă‚’äœœæˆă—ăŠă€ć…šăŠăźăƒŹăƒ—ăƒȘă‚«ăŒæœ€æ–°(PodăŒæœ€æ–°ăźPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă‚’ć«ă‚“ă§ă„ă‚‹)にăȘă‚Šă€ćˆ©ç”šćŻèƒœăšăȘっどいるこべをçąșèȘă—ăŠăă ă•ă„ă€‚ + + 5. Deploymentă«ă‚ˆăŁăŠäœœæˆă•ă‚ŒăŸReplicaSet (`rs`)をçąșèȘă™ă‚‹ă«ăŻ`kubectl get rs`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ă‚łăƒžăƒłăƒ‰ăźćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + + ```shell + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + ReplicaSetぼ損才は`[Deployment損]-[ăƒ©ăƒłăƒ€ăƒ æ–‡ć­—ćˆ—]`ăšă„ă†ćœąćŒă«ăȘă‚‹ă“ăšă«æłšæ„ă—ăŠăă ă•ă„ă€‚ăƒ©ăƒłăƒ€ăƒ æ–‡ć­—ćˆ—ăŻăƒ©ăƒłăƒ€ăƒ ă«ç”Ÿæˆă•ă‚Œă€pod-template-hashă‚’ă‚·ăƒŒăƒ‰ăšă—ăŠäœżç”šă—ăŸă™ă€‚ + + 6. 搄Podă«ăƒ©ăƒ™ăƒ«ăŒè‡Șć‹•çš„ă«ä»˜ă‘ă‚‰ă‚Œă‚‹ăźă‚’çąșèȘă™ă‚‹ă«ăŻ`kubectl get pods --show-labels`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ă‚łăƒžăƒłăƒ‰ăźćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ```shell + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + äœœæˆă•ă‚ŒăŸReplicaSetは`nginx`Podを3ă€äœœæˆă™ă‚‹ă“ăšă‚’äżèšŒă—ăŸă™ă€‚ + + {{< note >}} + Deploymentă«ćŻŸă—ăŠé©ćˆ‡ăȘă‚»ăƒŹă‚Żă‚żăƒŒăšPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăźăƒ©ăƒ™ăƒ«ă‚’èš­ćźšă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™(ă“ăźă‚±ăƒŒă‚čでは`app: nginx`)ă€‚ăƒ©ăƒ™ăƒ«ă‚„ă‚»ăƒŹă‚Żă‚żăƒŒă‚’ä»–ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšé‡è€‡ă•ă›ăȘいでください(他たDeploymentやStatefulSetを搫む)。KubernetesăŻăƒŠăƒŒă‚¶ăŒăƒ©ăƒ™ăƒ«ă‚’é‡è€‡ă•ă›ă‚‹ă“ăšă‚’æ­ąă‚ăȘă„ăŸă‚ă€è€‡æ•°ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă§ă‚»ăƒŹă‚Żă‚żăƒŒăźé‡è€‡ăŒç™șç”Ÿă™ă‚‹ăšă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒé–“ă§èĄçȘă—äșˆæœŸă›ăŹă”ă‚‹ăŸă„ă‚’ă™ă‚‹ă“ăšă«ăȘă‚ŠăŸă™ă€‚ + {{< /note >}} + +### pod-template-hashăƒ©ăƒ™ăƒ« + +{{< note >}} +ă“ăźăƒ©ăƒ™ăƒ«ă‚’ć€‰æ›Žă—ăȘいでください。 +{{< /note >}} + +`pod-template-hash`ăƒ©ăƒ™ăƒ«ăŻDeploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠDeploymentăŒäœœæˆă—é©ç”šă—ăŸć„ReplicaSetă«ćŻŸă—ăŠèżœćŠ ă•ă‚ŒăŸă™ă€‚ + +ă“ăźăƒ©ăƒ™ăƒ«ăŻDeploymentが缡理するReplicaSetăŒé‡è€‡ă—ăȘă„ă“ăšă‚’äżèšŒă—ăŸă™ă€‚ă“ăźăƒ©ăƒ™ăƒ«ăŻReplicaSetた`PodTemplate`ă‚’ăƒăƒƒă‚·ăƒ„ćŒ–ă™ă‚‹ă“ăšă«ă‚ˆă‚Šç”Ÿæˆă•ă‚Œă€ç”Ÿæˆă•ă‚ŒăŸăƒăƒƒă‚·ăƒ„ć€€ăŻăƒ©ăƒ™ăƒ«ć€€ăšă—ăŠReplicaSetă‚»ăƒŹă‚Żă‚żăƒŒă€Podăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăƒ©ăƒ™ăƒ«ă€ReplicaSetăŒäœœæˆă—ăŸć…šăŠăźPodă«ćŻŸă—ăŠèżœćŠ ă•ă‚ŒăŸă™ă€‚ + +## Deploymentăźæ›Žæ–° + +{{< note >}} +Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŻă€DeploymentたPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆ(こぼ栮搈`.spec.template`)ăŒć€‰æ›Žă•ă‚ŒăŸć Žćˆă«ăźăżăƒˆăƒȘă‚ŹăƒŒă•ă‚ŒăŸă™ă€‚äŸ‹ăˆă°ăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăźăƒ©ăƒ™ăƒ«ă‚‚ă—ăăŻă‚łăƒłăƒ†ăƒŠăƒŒă‚€ăƒĄăƒŒă‚žăŒæ›Žæ–°ă•ă‚ŒăŸć Žćˆă§ă™ă€‚Deploymentたă‚čă‚±ăƒŒăƒ«ăźă‚ˆă†ăȘæ›Žæ–°ă§ăŻă€ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŻăƒˆăƒȘă‚ŹăƒŒă•ă‚ŒăŸă›ă‚“ă€‚ +{{< /note >}} + +Deploymentă‚’æ›Žæ–°ă™ă‚‹ă«ăŻäž‹èš˜ăźă‚čăƒ†ăƒƒăƒ—ă«ćŸ“ăŁăŠăă ă•ă„ă€‚ + +1. nginxたPodで、`nginx:1.7.9`ă‚€ăƒĄăƒŒă‚žăźä»Łă‚ă‚Šă«`nginx:1.9.1`ă‚’äœżă†ă‚ˆă†ă«æ›Žæ–°ă—ăŸă™ă€‚ + + ```shell + kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment image updated + ``` + + ăŸăŸă€Deploymentを`線集`しど、`.spec.template.spec.containers[0].image`を`nginx:1.7.9`から`nginx:1.9.1`ă«ć€‰æ›Žă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ + + ```shell + kubectl edit deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment edited + ``` + +2. ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă™ă‚‹ă«ăŻă€äž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + ``` + もしくは + ``` + deployment.apps/nginx-deployment successfully rolled out + ``` + +æ›Žæ–°ă•ă‚ŒăŸDeploymentぼさらăȘă‚‹æƒ…ć ±ă‚’ć–ćŸ—ă™ă‚‹ă«ăŻă€äž‹èš˜ă‚’çąșèȘă—ăŠăă ă•ă„ă€‚ + +* ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒæˆćŠŸă—ăŸă‚ăšă€`kubectl get deployments`ă‚’ćźŸèĄŒă—ăŠDeploymentをçąșèȘă§ăăŸă™ă€‚ + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 36s + ``` + +* DeploymentăŒæ–°ă—ă„ReplicaSetă‚’äœœæˆă—ăŠPodă‚’æ›Žæ–°ă•ă›ăŸă‚Šă€æ–°ă—ă„ReplicaSetぼレプăƒȘă‚«ă‚’3にă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă›ăŸă‚Šă€ć€ă„ReplicaSetぼレプăƒȘă‚«ă‚’0にă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă›ă‚‹ăźă‚’çąșèȘă™ă‚‹ă«ăŻ`kubectl get rs`ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ + + ```shell + kubectl get rs + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 6s + nginx-deployment-2035384211 0 0 0 36s + ``` + +* `get pods`ă‚’ćźŸèĄŒă•ă›ă‚‹ăšă€æ–°ă—ă„PodたみçąșèȘă§ăăŸă™ă€‚ + + ```shell + kubectl get pods + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-khku8 1/1 Running 0 14s + nginx-deployment-1564180365-nacti 1/1 Running 0 14s + nginx-deployment-1564180365-z9gth 1/1 Running 0 14s + ``` + + æŹĄă«Podă‚’æ›Žæ–°ă•ă›ăŸă„ăšăăŻă€DeploymentたPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă‚’ć†ćșŠæ›Žæ–°ă™ă‚‹ă ă‘です。 + + Deploymentは、PodăŒæ›Žæ–°ă•ă‚ŒăŠă„ă‚‹é–“ă«ç‰čćźšăźæ•°ăźPodăźăżćœæ­ąçŠ¶æ…‹ă«ăȘă‚‹ă“ăšă‚’äżèšŒă—ăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻă€ç›źæš™ăšă™ă‚‹Podæ•°ăźć°‘ăȘくべも25%ăŒćœæ­ąçŠ¶æ…‹ă«ăȘă‚‹ă“ăšă‚’äżèšŒă—ăŸă™(25% max unavailable)。 + + ăŸăŸă€DeploymentはPodăŒæ›Žæ–°ă•ă‚ŒăŠă„ă‚‹é–“ă«ă€ç›źæš™ăšă™ă‚‹Podæ•°ă‚’ç‰čćźšăźæ•°ăŸă§è¶…ăˆăŠPodă‚’çšŒćƒă•ă›ă‚‹ă“ăšă‚’äżèšŒă—ăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻă€ç›źæš™ăšă™ă‚‹Podæ•°ă«ćŻŸă—ăŠæœ€ć€§ă§ă‚‚25%ă‚’è¶…ăˆăŠPodă‚’çšŒćƒă•ă›ă‚‹ă“ăšă‚’äżèšŒă—ăŸă™(25% max surge)。 + + äŸ‹ăˆă°ă€äžŠèš˜ă§èȘŹæ˜Žă—ăŸDeploymentăźçŠ¶æ…‹ă‚’æłšæ„æ·±ăèŠ‹ă‚‹ăšă€æœ€ćˆă«æ–°ă—ă„PodăŒäœœæˆă•ă‚Œă€æŹĄă«ć€ă„PodăŒć‰Šé™€ă•ă‚Œă‚‹ăźă‚’çąșèȘă§ăăŸă™ă€‚ććˆ†ăȘæ•°ăźæ–°ă—ă„PodăŒçšŒćƒă™ă‚‹ăŸă§ăŻă€DeploymentăŻć€ă„Podă‚’ć‰Šé™€ă—ăŸă›ă‚“ă€‚ăŸăŸććˆ†ăȘæ•°ăźć€ă„PodăŒć‰Šé™€ă—ăȘă„é™ă‚Šæ–°ă—ă„PodăŻäœœæˆă•ă‚ŒăŸă›ă‚“ă€‚ć°‘ăȘくべも2぀たPodăŒćˆ©ç”šćŻèƒœă§ă€æœ€ć€§ă§ă‚‚ăƒˆăƒŒă‚żăƒ«ă§4぀たPodăŒćˆ©ç”šćŻèƒœă«ăȘăŁăŠă„ă‚‹ă“ăšă‚’äżèšŒă—ăŸă™ă€‚ + +* Deploymentăźè©łçŽ°æƒ…ć ±ă‚’ć–ćŸ—ă—ăŸă™ă€‚ + ```shell + kubectl describe deployments + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=2 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 + ``` + æœ€ćˆă«Deploymentă‚’äœœæˆă—ăŸæ™‚ă€ReplicaSet(nginx-deployment-2035384211)ă‚’äœœæˆă—ăŠă™ăă«ăƒŹăƒ—ăƒȘă‚«æ•°ă‚’3にă‚čă‚±ăƒŒăƒ«ă™ă‚‹ăźă‚’çąșèȘă§ăăŸă™ă€‚Deploymentă‚’æ›Žæ–°ă™ă‚‹ăšæ–°ă—ă„ReplicaSet(nginx-deployment-1564180365)ă‚’äœœæˆă—ăŠăƒŹăƒ—ăƒȘă‚«æ•°ă‚’1にă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă—ă€ć€ă„ReplicaSeetを2にă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă›ăŸă™ă€‚ă“ă‚ŒăŻćžžă«æœ€äœŽă§ă‚‚2぀たPodăŒćˆ©ç”šćŻèƒœă§ă€ă‹ă€æœ€ć€§4぀たPodăŒäœœæˆă•ă‚ŒăŠă„ă‚‹çŠ¶æ…‹ă«ă™ă‚‹ăŸă‚ă§ă™ă€‚DeploymentăŻćŒă˜ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—æˆŠç•„ă«ćŸ“ăŁăŠæ–°ă—ă„ReplicaSetたă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ăšć€ă„ReplicaSetたă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă‚’ç¶šă‘ăŸă™ă€‚æœ€ç”‚çš„ă«æ–°ă—ă„ReplicaSetを3にă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă›ă€ć€ă„ReplicaSetを0にă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă›ăŸă™ă€‚ + +### ăƒ­ăƒŒăƒ«ă‚ȘăƒŒăƒăƒŒ (ăƒȘă‚ąăƒ«ă‚żă‚€ăƒ ă§ăźè€‡æ•°ăźPodăźæ›Žæ–°) + +Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆă‚Šă€æ–°ă—ă„DeploymentăŒèŠłæžŹă•ă‚Œă‚‹ćșŠă«ReplicaSetăŒäœœæˆă•ă‚Œă€ç†æƒłăšă™ă‚‹ăƒŹăƒ—ăƒȘă‚«æ•°ăźPodă‚’äœœæˆă—ăŸă™ă€‚DeploymentăŒæ›Žæ–°ă•ă‚Œă‚‹ăšă€æ—ąć­˜ăźReplicaSetが缡理するPodăźăƒ©ăƒ™ăƒ«ăŒ`.spec.selector`ă«ăƒžăƒƒăƒă™ă‚‹ăŒă€ăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăŒ`.spec.template`ă«ăƒžăƒƒăƒă—ăȘい栮搈はă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă‚ŒăŸă™ă€‚æœ€ç”‚çš„ă«ă€æ–°ă—ă„ReplicaSetは`.spec.replicas`た怀にă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă‚Œă€ć€ă„ReplicaSetは0にă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă‚ŒăŸă™ă€‚ + +Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒé€ČèĄŒäž­ă«Deploymentă‚’æ›Žæ–°ă™ă‚‹ăšă€DeploymentăŻæ›Žæ–°ă™ă‚‹æŻŽă«æ–°ă—ă„ReplicaSetă‚’äœœæˆă—ăŠă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă›ă€ä»„ć‰ă«ă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă—ăŸReplicaSetăźăƒ­ăƒŒăƒ«ă‚ȘăƒŒăƒăƒŒă‚’èĄŒă„ăŸă™ă€‚DeploymentăŻæ›Žæ–°ć‰ăźReplicaSetă‚’ć€ă„ReplicaSetたăƒȘă‚čăƒˆă«èżœćŠ ă—ă€ă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă‚’é–‹ć§‹ă—ăŸă™ă€‚ + +äŸ‹ăˆă°ă€5ă€ăźăƒŹăƒ—ăƒȘă‚«ă‚’æŒă€`nginx:1.7.9`たDeploymentă‚’äœœæˆă—ă€`nginx:1.7.9`た3ă€ăźăƒŹăƒ—ăƒȘă‚«ăŒäœœæˆă•ă‚ŒăŠă„ă‚‹ăšăă«5ă€ăźăƒŹăƒ—ăƒȘă‚«ă‚’æŒă€`nginx:1.9.1`ă«æ›Žæ–°ă—ăŸă™ă€‚ă“ăźă‚±ăƒŒă‚čではDeploymentăŻäœœæˆæžˆăżăź`nginx:1.7.9`た3぀たPodをすぐに扊陀し、`nginx:1.9.1`たPodăźäœœæˆă‚’é–‹ć§‹ă—ăŸă™ă€‚`nginx:1.7.9`た5ă€ăźăƒŹăƒ—ăƒȘă‚«ă‚’ć…šăŠäœœæˆă™ă‚‹ăźă‚’ćŸ…ă€ă“ăšăŻă‚ă‚ŠăŸă›ă‚“ă€‚ + +### ăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒăźæ›Žæ–° + +é€šćžžă€ăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒă‚’æ›Žæ–°ă™ă‚‹ă“ăšăŻæŽšć„šă•ă‚ŒăŸă›ă‚“ă€‚äș‹ć‰ă«ăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒăźäœżă„æ–čă‚’èšˆç”»ă—ăŠăŠăăŸă—ă‚‡ă†ă€‚ă„ă‹ăȘă‚‹ć Žćˆă§ă‚ăŁăŠă‚‚æ›Žæ–°ăŒćż…èŠăȘăšăăŻććˆ†ă«æłšæ„ă‚’æ‰•ă„ă€ć€‰æ›Žæ™‚ăźćœ±éŸżçŻ„ć›Čă‚’æŠŠæĄă—ăŠăŠăăŸă—ă‚‡ă†ă€‚ + +{{< note >}} +`apps/v1`API ăƒăƒŒă‚žăƒ§ăƒłă«ăŠă„ăŠă€Deploymentăźăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒăŻäœœæˆćŸŒă«äžć€‰ăšăȘă‚ŠăŸă™ă€‚ +{{< /note >}} + +* ă‚»ăƒŹă‚Żă‚żăƒŒăźèżœćŠ ăŻă€Deployment Specăźăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăƒ©ăƒ™ăƒ«ă‚‚æ–°ă—ă„ăƒ©ăƒ™ăƒ«ă§æ›Žæ–°ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ăă†ă§ăȘい栮搈はバăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłă‚šăƒ©ăƒŒăŒèż”ă•ă‚ŒăŸă™ă€‚ă“ăźć€‰æ›ŽăŻé‡è€‡ăŒăȘă„æ›Žæ–°ăšăȘă‚ŠăŸă™ă€‚ă“ă‚ŒăŻæ–°ă—ă„ă‚»ăƒŹă‚Żă‚żăƒŒăŻć€ă„ă‚»ăƒŹă‚Żă‚żăƒŒă‚’æŒă€ReplicaSetずPodă‚’éžæŠžă›ăšă€ç”æžœăšă—ăŠć€ă„ć…šăŠăźReplicaSetがみăȘă—ć­çŠ¶æ…‹ă«ăȘă‚Šă€æ–°ă—ă„ReplicaSetă‚’äœœæˆă™ă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ +* ă‚»ăƒŹă‚Żă‚żăƒŒăźæ›Žæ–°ă«ă‚ˆă‚Šă€ă‚»ăƒŹă‚Żă‚żăƒŒă‚­ăƒŒć†…ăźæ—ąć­˜ăźć€€ăŒć€‰æ›Žă•ă‚ŒăŸă™ă€‚ă“ă‚Œă«ă‚ˆă‚Šă€ă‚»ăƒŹă‚Żă‚żăƒŒăźèżœćŠ ăšćŒă˜ă”ă‚‹ăŸă„ă‚’ă—ăŸă™ă€‚ +* ă‚»ăƒŹă‚Żă‚żăƒŒăźć‰Šé™€ă«ă‚ˆă‚Šă€Deploymentăźă‚»ăƒŹă‚Żă‚żăƒŒă‹ă‚‰ć­˜ćœšă—ăŠă„ă‚‹ć€€ă‚’ć‰Šé™€ă—ăŸă™ă€‚ă“ă‚ŒăŻPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăźăƒ©ăƒ™ăƒ«ă«é–ąă™ă‚‹ć€‰æ›Žă‚’èŠæ±‚ă—ăŸă›ă‚“ă€‚æ—ąć­˜ăźReplicaSetはみăȘă—ć­çŠ¶æ…‹ă«ăȘă‚‰ăšă€æ–°ă—ă„ReplicaSetăŻäœœæˆă•ă‚ŒăŸă›ă‚“ăŒă€ć‰Šé™€ă•ă‚ŒăŸăƒ©ăƒ™ăƒ«ăŻæ—ąć­˜ăźPodずReplicaSetă§ăŻæź‹ă‚Šç¶šă‘ăŸă™ă€‚ + +## Deploymentăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Ż {#rolling-back-a-deployment} + +Deploymentăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă‚’èĄŒă„ăŸă„ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚äŸ‹ăˆă°ă€DeploymentăŒă‚Żăƒ©ăƒƒă‚·ăƒ„çŠ¶æ…‹ă«ăȘă‚Šăă‚ŒăŒăƒ«ăƒŒăƒ—ă—ăŸă‚Šă™ă‚‹äžćź‰ćźšăȘăšăă§ă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻăƒŠăƒŒă‚¶ăƒŒăŒă„ă€ă§ă‚‚ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă§ăă‚‹ă‚ˆă†ă«Deploymentăźć…šăŠăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆć±„æ­ŽăŒă‚·ă‚čăƒ†ăƒ ă«äżæŒă•ă‚ŒăŸă™(ăƒȘăƒ“ă‚žăƒ§ăƒłć±„æ­ŽăźäžŠé™ăŻèš­ćźšă™ă‚‹ă“ăšă§ć€‰æ›ŽćŻèƒœă§ă™)。 + +{{< note >}} +DeploymentたăƒȘビゾョンは、Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒăƒˆăƒȘă‚ŹăƒŒă•ă‚ŒăŸæ™‚ă«äœœæˆă•ă‚ŒăŸă™ă€‚ă“ă‚ŒăŻDeploymentたPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆ(`.spec.template`)ăŒć€‰æ›Žă•ă‚ŒăŸăšăăźăżæ–°ă—ă„ăƒȘăƒ“ă‚žăƒ§ăƒłăŒäœœæˆă•ă‚Œă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚Deploymentたă‚čă‚±ăƒŒăƒȘングăȘă©ă€ä»–ăźçšźéĄžăźæ›Žæ–°ă«ăŠă„ăŠăŻDeploymentたăƒȘăƒ“ă‚žăƒ§ăƒłăŻäœœæˆă•ă‚ŒăŸă›ă‚“ă€‚ă“ă‚ŒăŻæ‰‹ć‹•ă‚‚ă—ăăŻă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒȘăƒłă‚°ă‚’ćŒæ™‚ă«èĄŒă†ă“ăšăŒă§ăă‚‹ă‚ˆă†ă«ă™ă‚‹ăŸă‚ă§ă™ă€‚ă“ă‚ŒăŻéŽćŽ»ăźăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă™ă‚‹ăšăă€DeploymentたPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăźçź‡æ‰€ăźăżăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă•ă‚Œă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ +{{< /note >}} + +* `nginx:1.9.1`ăźä»Łă‚ă‚Šă«`nginx:1.91`ăšă„ă†ă‚€ăƒĄăƒŒă‚žă«æ›Žæ–°ă—ăŠă€Deploymentăźæ›Žæ–°äž­ă«ă‚żă‚€ăƒ—ăƒŸă‚čă‚’ă—ăŸăšä»źćźšă—ăŸă™ă€‚ + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment image updated + ``` + +* ă“ăźăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŻă†ăŸăă„ăăŸă›ă‚“ă€‚ăƒŠăƒŒă‚¶ăƒŒăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čă‚’èŠ‹ă‚‹ă“ăšă§ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒă†ăŸăă„ăă‹çąșèȘă§ăăŸă™ă€‚ + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + Waiting for rollout to finish: 1 out of 3 new replicas have been updated... + ``` + +* ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čたçąșèȘăŻă€Ctrl-Că‚’æŠŒă™ă“ăšă§ćœæ­ąă§ăăŸă™ă€‚ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒă†ăŸăèĄŒă‹ăȘいべきは、[Deploymentたă‚čăƒ†ăƒŒă‚żă‚č](#deployment-status)をèȘ­ă‚“でさらăȘă‚‹æƒ…ć ±ă‚’ćŸ—ăŠăă ă•ă„ă€‚ + +* ć€ă„ăƒŹăƒ—ăƒȘă‚«æ•°(`nginx-deployment-1564180365` and `nginx-deployment-2035384211`)が2にăȘっどいるこべをçąșèȘă§ăă€æ–°ă—ă„ăƒŹăƒ—ăƒȘă‚«æ•°(nginx-deployment-3066724191)は1にăȘăŁăŠă„ăŸă™ă€‚ + + ```shell + kubectl get rs + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 25s + nginx-deployment-2035384211 0 0 0 36s + nginx-deployment-3066724191 1 1 0 6s + ``` + +* äœœæˆă•ă‚ŒăŸPodをçąșèȘă—ăŠă„ă‚‹ăšă€æ–°ă—ă„ReplicaSetă«ă‚ˆăŁăŠäœœæˆă•ă‚ŒăŸ1぀たPodăŻă‚łăƒłăƒ†ăƒŠă‚€ăƒĄăƒŒă‚žăźpullă«ć€±æ•—ă—ç¶šă‘ăŠă„ă‚‹ăźăŒă‚ă‹ă‚ŠăŸă™ă€‚ + + ```shell + kubectl get pods + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-70iae 1/1 Running 0 25s + nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s + nginx-deployment-1564180365-hysrc 1/1 Running 0 25s + nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s + ``` + + {{< note >}} + Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă€ă“ăźæ‚Șă„çŠ¶æ…‹ăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’è‡Șć‹•çš„ă«ćœæ­ąă—ă€æ–°ă—ă„ReplicaSetたă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă‚’æ­ąă‚ăŸă™ă€‚ă“ă‚ŒăŻăƒŠăƒŒă‚¶ăƒŒăŒæŒ‡ćźšă—ăŸăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆă«é–ąă™ă‚‹ăƒ‘ăƒ©ăƒĄăƒŒă‚ż(ç‰čに`maxUnavailable`)ă«äŸć­˜ă—ăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻKubernetesăŒă“ăźć€€ă‚’25%ă«èš­ćźšă—ăŸă™ă€‚ + {{< /note >}} + +* Deploymentăźè©łçŽ°æƒ…ć ±ă‚’ć–ćŸ—ă—ăŸă™ă€‚ + ```shell + kubectl describe deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 + Labels: app=nginx + Selector: app=nginx + Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) + NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 + ``` + + ă“ă‚Œă‚’äżźæ­Łă™ă‚‹ăŸă‚ă«ă€Deploymentă‚’ćź‰ćźšă—ăŸçŠ¶æ…‹ăźéŽćŽ»ăźăƒȘăƒ“ă‚žăƒ§ăƒłă«æ›Žæ–°ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ + +### Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆć±„æ­ŽăźçąșèȘ + +ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźć±„æ­Žă‚’çąșèȘă™ă‚‹ă«ăŻă€äž‹èš˜ăźæ‰‹é †ă«ćŸ“っお䞋さい。 + +1. æœ€ćˆă«ă€DeploymentたăƒȘビゾョンをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployments "nginx-deployment" + REVISION CHANGE-CAUSE + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true + 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + `CHANGE-CAUSE`はăƒȘăƒ“ă‚žăƒ§ăƒłăźäœœæˆæ™‚ă«Deploymentた`kubernetes.io/change-cause`ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłă‹ă‚‰ăƒȘăƒ“ă‚žăƒ§ăƒłă«ă‚łăƒ”ăƒŒă•ă‚ŒăŸă™ă€‚äž‹èš˜ăźæ‰‹æź”ă«ă‚ˆă‚Š`CHANGE-CAUSE`ăƒĄăƒƒă‚»ăƒŒă‚žă‚’æŒ‡ćźšă§ăăŸă™ă€‚ + + * `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`ăźćźŸèĄŒă«ă‚ˆă‚Šă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłă‚’èżœćŠ ă™ă‚‹ă€‚ + * ăƒȘă‚œăƒŒă‚čăźć€‰æ›Žæ™‚ă«`kubectl`コマンドぼ憅ćźčă‚’èš˜éŒČă™ă‚‹ăŸă‚ă«`--record`ăƒ•ăƒ©ă‚°ă‚’èżœćŠ ă™ă‚‹ă€‚ + * ăƒȘă‚œăƒŒă‚čぼマニフェă‚čăƒˆă‚’æ‰‹ć‹•ă§ç·šé›†ă™ă‚‹ă€‚ + +2. 搄ăƒȘăƒ“ă‚žăƒ§ăƒłăźè©łçŽ°ă‚’çąșèȘă™ă‚‹ăŸă‚ă«ăŻäž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. + ``` + +### 過掻たăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă™ă‚‹ {#rolling-back-to-a-previous-revision} +çŸćœšăźăƒȘăƒ“ă‚žăƒ§ăƒłă‹ă‚‰éŽćŽ»ăźăƒȘビゾョン(ăƒȘビゾョンç•Șć·2)ă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă•ă›ă‚‹ă«ăŻă€äž‹èš˜ăźæ‰‹é †ă«ćŸ“ăŁăŠăă ă•ă„ă€‚ + +1. çŸćœšăźăƒȘăƒ“ă‚žăƒ§ăƒłă‹ă‚‰éŽćŽ»ăźăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă—ăŸă™ă€‚ + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment + ``` + ăăźä»–ă«ă€`--to-revision`ă‚’æŒ‡ćźšă™ă‚‹ă“ăšă«ă‚ˆă‚Šç‰č漚ぼăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă§ăăŸă™ă€‚ + + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment + ``` + + ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă«é–ąé€Łă—ăŸă‚łăƒžăƒłăƒ‰ăźă•ă‚‰ăȘă‚‹æƒ…ć ±ăŻ[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を揂照しどください。 + + DeploymentăŒéŽćŽ»ăźćź‰ćźšă—ăŸăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă•ă‚ŒăŸă—ăŸă€‚Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠă€ăƒȘビゾョンç•Șć·2ă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă™ă‚‹`DeploymentRollback`ă‚€ăƒ™ăƒłăƒˆăŒäœœæˆă•ă‚ŒăŸăźă‚’çąșèȘă§ăăŸă™ă€‚ + +2. ăƒ­ăƒŒăƒ«ăƒăƒƒă‚ŻăŒæˆćŠŸă—ă€DeploymentăŒæ­Łćžžă«çšŒćƒă—ăŠă„ă‚‹ă“ăšă‚’çąșèȘă™ă‚‹ăŸă‚ă«ă€äž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠăă ă•ă„ă€‚ + ```shell + kubectl get deployment nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 30m + ``` +3. Deploymentăźè©łçŽ°æƒ…ć ±ă‚’ć–ćŸ—ă—ăŸă™ă€‚ + ```shell + kubectl describe deployment nginx-deployment + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 + ``` + +## Deploymentたă‚čă‚±ăƒŒăƒȘング {#scaling-a-deployment} +äž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă•ă›ăŠDeploymentをă‚čă‚±ăƒŒăƒ«ă§ăăŸă™ă€‚ + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` + +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +deployment.apps/nginx-deployment scaled +``` + +ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă§[æ°ŽćčłPodă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ©ăƒŒ](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)ăŒæœ‰ćŠčにăȘăŁăŠă„ă‚‹ăšä»źćźšă—ăŸă™ă€‚ă“ă“ă§Deploymentたă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ©ăƒŒă‚’èš­ćźšă—ă€çšŒćƒă—ăŠă„ă‚‹PodたCPUäœżç”šé‡ă«ćŸșă„ă„ăŠă€ăƒŠăƒŒă‚¶ăƒŒăŒçšŒćƒă•ă›ăŸă„PodぼレプăƒȘă‚«æ•°ăźæœ€ć°ć€€ăšæœ€ć€§ć€€ă‚’èš­ćźšă§ăăŸă™ă€‚ + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +deployment.apps/nginx-deployment scaled +``` + +### æŻ”äŸ‹ă‚čă‚±ăƒŒăƒȘング + +Deploymentăźăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăŻă€ćŒæ™‚ă«è€‡æ•°ăźăƒăƒŒă‚žăƒ§ăƒłăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźçšŒćƒă‚’ă‚”ăƒăƒŒăƒˆă—ăŸă™ă€‚ăƒŠăƒŒă‚¶ăƒŒă‚„ă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ©ăƒŒăŒăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆäž­(æ›Žæ–°äž­ă‚‚ă—ăăŻäž€æ™‚ćœæ­ąäž­)たDeploymentăźăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆă‚’èĄŒă†ăšăă€Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻăƒȘă‚čă‚Żă‚’ć‰Šæž›ă™ă‚‹ăŸă‚ă«æ—ąć­˜ăźă‚ąă‚Żăƒ†ă‚Łăƒ–ăȘReplicaSetぼレプăƒȘă‚«ăźăƒăƒ©ăƒłă‚·ăƒłă‚°ă‚’èĄŒă„ăŸă™ă€‚ă“ă‚Œă‚’*æŻ”äŸ‹ă‚čă‚±ăƒŒăƒȘング* ăšć‘ŒăłăŸă™ă€‚ + +レプăƒȘă‚«æ•°ăŒ10、[maxSurge](#max-surge)=3、[maxUnavailable](#max-unavailable)=2であるDeploymentăŒçšŒćƒă—ăŠă„ă‚‹äŸ‹ă§ă™ă€‚ + +* Deployment憅で10ぼレプăƒȘă‚«ăŒçšŒćƒă—ăŠă„ă‚‹ă“ăšă‚’çąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get deploy + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 10 10 10 10 50s + ``` + +* ă‚Żăƒ©ă‚čă‚żăƒŒć†…ă§ă€è§Łæ±șできăȘă„æ–°ă—ă„ă‚€ăƒĄăƒŒă‚žă«æ›Žæ–°ă—ăŸă™ă€‚ +* You update to a new image which happens to be unresolvable from inside the cluster. + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + The output is similar to this: + ``` + deployment.apps/nginx-deployment image updated + ``` + +* ă‚€ăƒĄăƒŒă‚žăźæ›Žæ–°ăŻæ–°ă—ă„ReplicaSet nginx-deployment-1989198191ăžăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’é–‹ć§‹ă•ă›ăŸă™ă€‚ă—ă‹ă—ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŻă€äžŠèż°ă—ăŸ`maxUnavailable`ăźèŠæ±‚ă«ă‚ˆă‚Šăƒ–ăƒ­ăƒƒă‚Żă•ă‚ŒăŸă™ă€‚ă“ă“ă§ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get rs + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 5 5 0 9s + nginx-deployment-618515232 8 8 8 1m + ``` + +* æŹĄă«Deploymentたă‚čă‚±ăƒŒăƒȘăƒłă‚°ă‚’ă™ă‚‹ăŸă‚ăźæ–°ă—ă„èŠæ±‚ăŒç™șç”Ÿă—ăŸă™ă€‚ă‚ȘăƒŒăƒˆă‚čă‚±ăƒŒăƒ©ăƒŒăŻDeploymentぼレプăƒȘă‚«æ•°ă‚’15ă«ćą—ă‚„ă—ăŸă™ă€‚Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻæ–°ă—ă„5ă€ăźăƒŹăƒ—ăƒȘă‚«ă‚’ă©ă“ă«èżœćŠ ă™ă‚‹ă‹æ±șă‚ă‚‹ćż…èŠăŒă§ăŠăăŸă™ă€‚æŻ”äŸ‹ă‚čă‚±ăƒŒăƒȘăƒłă‚°ă‚’äœżç”šă—ăŠă„ăȘい栮搈、5ă€ăźăƒŹăƒ—ăƒȘă‚«ăŻć…šăŠæ–°ă—ă„ReplicaSetă«èżœćŠ ă•ă‚ŒăŸă™ă€‚æŻ”äŸ‹ă‚čă‚±ăƒŒăƒȘăƒłă‚°ă§ăŻă€èżœćŠ ă•ă‚Œă‚‹ăƒŹăƒ—ăƒȘカは慚おたReplicaSetă«ćˆ†æ•Łă•ă‚ŒăŸă™ă€‚æŻ”äŸ‹ć‰ČćˆăŒć€§ăă„ă‚‚ăźăŻăƒŹăƒ—ăƒȘă‚«æ•°ăźć€§ăă„ReplicaSetずăȘă‚Šă€æŻ”äŸ‹ć‰ČćˆăŒäœŽă„ăšăăŻăƒŹăƒ—ăƒȘă‚«æ•°ăźć°ă•ă„ReplicaSetずăȘă‚ŠăŸă™ă€‚æź‹ăŁăŠă„ă‚‹ăƒŹăƒ—ăƒȘă‚«ăŻă‚‚ăŁăšă‚‚ć€§ăă„ăƒŹăƒ—ăƒȘă‚«æ•°ă‚’æŒă€ReplicaSetă«èżœćŠ ă•ă‚ŒăŸă™ă€‚ăƒŹăƒ—ăƒȘă‚«æ•°ăŒ0たReplicaSetはă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă‚ŒăŸă›ă‚“ă€‚ + +äžŠèš˜ăźäŸ‹ă§ăŻă€3ă€ăźăƒŹăƒ—ăƒȘă‚«ăŒć€ă„ReplicaSetă«èżœćŠ ă•ă‚Œă€2ă€ăźăƒŹăƒ—ăƒȘă‚«ăŒæ–°ă—ă„ReplicaSetă«èżœćŠ ă•ă‚ŒăŸă—ăŸă€‚ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźć‡Šç†ă§ăŻă€æ–°ă—ă„ăƒŹăƒ—ăƒȘă‚«æ•°ăźPodăŒæ­Łćžžă«ăȘăŁăŸăšä»źćźšă™ă‚‹ăšă€æœ€ç”‚çš„ă«æ–°ă—ă„ReplicaSetă«ć…šăŠăźăƒŹăƒ—ăƒȘă‚«ă‚’ç§»ć‹•ă•ă›ăŸă™ă€‚ă“ă‚Œă‚’çąșèȘă™ă‚‹ăŸă‚ă«ăŻäž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠäž‹ă•ă„ă€‚ + + ```shell + kubectl get deploy + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 15 18 7 8 7m + ``` + ă€€ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čでレプăƒȘă‚«ăŒă©ăźă‚ˆă†ă«ć„ReplicaSetă«èżœćŠ ă•ă‚Œă‚‹ă‹çąșèȘă§ăăŸă™ă€‚ + ```shell + kubectl get rs + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 7 7 0 7m + nginx-deployment-618515232 11 11 11 7m + ``` + +## Deploymentæ›Žæ–°ăźäž€æ™‚ćœæ­ąăšć†é–‹ {#pausing-and-resuming-a-deployment} + +ăƒŠăƒŒă‚¶ăƒŒăŻ1ă€ä»„äžŠăźæ›Žæ–°ć‡Šç†ă‚’ăƒˆăƒȘă‚ŹăƒŒă™ă‚‹ć‰ă«æ›Žæ–°ăźäž€æ™‚ćœæ­ąăšć†é–‹ăŒă§ăăŸă™ă€‚ă“ă‚Œă«ă‚ˆă‚Šă€äžćż…èŠăȘăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’ćźŸèĄŒă™ă‚‹ă“ăšăȘăäž€æ™‚ćœæ­ąăšć†é–‹ă‚’èĄŒă†é–“ă«è€‡æ•°ăźäżźæ­Łă‚’ćæ˜ ă§ăăŸă™ă€‚ + +* äŸ‹ăˆă°ă€äœœæˆç›ŽćŸŒăźDeploymentă‚’è€ƒăˆăŸă™ă€‚ + Deploymentăźè©łçŽ°æƒ…ć ±ă‚’çąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get deploy + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx 3 3 3 3 1m + ``` + ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get rs + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 1m + ``` + +* äž‹èš˜ăźă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒă—ăŠæ›Žæ–°ć‡Šç†ăźäž€æ™‚ćœæ­ąă‚’èĄŒă„ăŸă™ă€‚ + ```shell + kubectl rollout pause deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment paused + ``` + +* æŹĄă«Deploymentăźă‚€ăƒĄăƒŒă‚žă‚’æ›Žæ–°ă—ăŸă™ă€‚ + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment image updated + ``` + +* æ–°ă—ă„ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒé–‹ć§‹ă•ă‚ŒăŠă„ăȘいこべをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployments "nginx" + REVISION CHANGE-CAUSE + 1 + ``` +* Deploymentăźæ›Žæ–°ă«æˆćŠŸă—ăŸă“ăšă‚’çąșèȘă™ă‚‹ăŸă‚ă«ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get rs + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 2m + ``` + +* ăƒŠăƒŒă‚¶ăƒŒăŻäœ•ćșŠă‚‚æ›Žæ–°ă‚’èĄŒăˆăŸă™ă€‚äŸ‹ăˆă°DeploymentăŒäœżç”šă™ă‚‹ăƒȘă‚œăƒŒă‚čă‚’æ›Žæ–°ă—ăŸă™ă€‚ + ```shell + kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment resource requirements updated + ``` + äž€æ™‚ćœæ­ąă™ă‚‹ć‰ăźćˆæœŸçŠ¶æ…‹ă§ăŻæ›Žæ–°ć‡Šç†ăŻæ©Ÿèƒœă—ăŸă™ăŒă€DeploymentăŒäž€æ™‚ćœæ­ąă•ă‚ŒăŠă„ă‚‹é–“ăŻæ–°ă—ă„æ›Žæ–°ć‡Šç†ăŻćæ˜ ă•ă‚ŒăŸă›ă‚“ă€‚ + +* æœ€ćŸŒă«ă€DeploymentăźçšŒćƒă‚’ć†é–‹ă•ă›ă€æ–°ă—ă„ReplicaSetăŒæ›Žæ–°ć†…ćźčă‚’ć…šăŠćæ˜ ă•ă›ăŠă„ă‚‹ăźă‚’çąșèȘă—ăŸă™ă€‚ + ```shell + kubectl rollout resume deployment.v1.apps/nginx-deployment + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + deployment.apps/nginx-deployment resumed + ``` +* æ›Žæ–°ć‡Šç†ăŒćźŒäș†ă™ă‚‹ăŸă§ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get rs -w + ``` + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 2 2 2 2m + nginx-3926361531 2 2 0 6s + nginx-3926361531 2 2 1 18s + nginx-2142116321 1 2 2 2m + nginx-2142116321 1 2 2 2m + nginx-3926361531 3 2 1 18s + nginx-3926361531 3 2 1 18s + nginx-2142116321 1 1 1 2m + nginx-3926361531 3 3 1 18s + nginx-3926361531 3 3 2 19s + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 20s + ``` +* æœ€æ–°ăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźă‚čăƒ†ăƒŒă‚żă‚čをçąșèȘă—ăŸă™ă€‚ + ```shell + kubectl get rs + ``` + + ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 28s + ``` +{{< note >}} +äž€æ™‚ćœæ­ąă—ăŸDeploymentăźçšŒćƒă‚’ć†é–‹ă•ă›ăȘă„é™ă‚Šă€ăƒŠăƒŒă‚¶ăƒŒăŻDeploymentăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚ŻăŻă§ăăŸă›ă‚“ă€‚ +{{< /note >}} + +## Deploymentたă‚čăƒ†ăƒŒă‚żă‚č {#deployment-status} + +DeploymentăŻă€ăăźăƒ©ă‚€ăƒ•ă‚”ă‚€ă‚Żăƒ«ăźé–“ă«æ§˜ă€…ăȘçŠ¶æ…‹ă«é·ç§»ă—ăŸă™ă€‚æ–°ă—ă„ReplicaSetăžăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆäž­ăŻ[é€ČèĄŒäž­](#progressing-deployment)にăȘă‚Šă€ăăźćŸŒăŻ[漌äș†](#complete-deployment)ă—ă€ăŸăŸ[ć€±æ•—](#failed-deployment)にもăȘă‚ŠăŸă™ă€‚ + +### Deploymentăźæ›Žæ–°ć‡Šç† {#progressing-deployment} + +äž‹èš˜ăźă‚żă‚čă‚ŻăŒćźŸèĄŒäž­ăźăšăă€KubernetesはDeploymentăźçŠ¶æ…‹ă‚’_progressing_ ă«ă—ăŸă™ă€‚ + +* DeploymentăŒæ–°ă—ă„ReplicaSetă‚’äœœæˆă™ă‚‹ă€‚ +* DeploymentăŒæ–°ă—ă„ReplicaSetをă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă›ăŠă„ă‚‹ă€‚ +* DeploymentăŒć€ă„ReplicaSetをă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă›ăŠă„ă‚‹ă€‚ +* æ–°ă—ă„Podがæș–ć‚™äž­ă‚‚ă—ăăŻćˆ©ç”šćŻèƒœăȘçŠ¶æ…‹ă«ăȘる(民ăȘくべも[MinReadySeconds](#min-ready-seconds)ぼ間はæș–悙䞭にăȘă‚ŠăŸă™)。 + +ăƒŠăƒŒă‚¶ăƒŒăŻ`kubectl rollout status`ă‚’ćźŸèĄŒă—ăŠDeploymentたé€ČèĄŒçŠ¶æ…‹ă‚’çąșèȘă§ăăŸă™ă€‚ + +### Deploymentăźæ›Žæ–°ć‡Šç†ăźćźŒäș† {#complete-deployment} + +DeploymentăŒäž‹èš˜ăźçŠ¶æ…‹ă«ăȘったべき、KubernetesはDeploymentたă‚čăƒ†ăƒŒă‚żă‚čを_complete_ ă«ă—ăŸă™ă€‚ + +* Deploymentぼ慹どぼレプăƒȘă‚«ăŒă€æŒ‡ćźšă•ă‚ŒăŸæœ€æ–°ăźăƒăƒŒă‚žăƒ§ăƒłă«æ›Žæ–°ă•ă‚Œă‚‹ă€‚ă“ă‚ŒăŻăƒŠăƒŒă‚¶ăƒŒăŒæŒ‡ćźšă—ăŸæ›Žæ–°ć‡Šç†ăŒćźŒäș†ă—ăŸă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚ +* Deploymentぼ慹どぼレプăƒȘă‚«ăŒćˆ©ç”šćŻèƒœă«ăȘる。 +* Deploymentăźć€ă„ăƒŹăƒ—ăƒȘă‚«ăŒ1ă€ă‚‚çšŒćƒă—ăŠă„ăȘい。 + +`kubectl rollout status`ă‚’ćźŸèĄŒă—ăŠă€Deploymentăźæ›Žæ–°ăŒćźŒäș†ă—ăŸă“ăšă‚’çąșèȘă§ăăŸă™ă€‚ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒæ­Łćžžă«ćźŒäș†ă™ă‚‹ăš`kubectl rollout status`た甂äș†ă‚łăƒŒăƒ‰ăŒ0ă§èż”ă•ă‚ŒăŸă™ă€‚ + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### Deploymentăźæ›Žæ–°ć‡Šç†ăźć€±æ•— {#failed-deployment} + +æ–°ă—ă„ReplicaSetăźăƒ‡ăƒ—ăƒ­ă‚€ăŒćźŒäș†ă›ăšă€æ›Žæ–°ć‡Šç†ăŒæ­ąăŸă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ă“ă‚ŒăŻäž»ă«äž‹èš˜ăźèŠć› ă«ă‚ˆă‚‹ă‚‚ăźă§ă™ă€‚ + +* 侍捁戆ăȘăƒȘă‚œăƒŒă‚čたć‰Čă‚Šćœ“ăŠ +* ReadinessProbeăźć€±æ•— +* ă‚łăƒłăƒ†ăƒŠă‚€ăƒĄăƒŒă‚žăźć–ćŸ—ăŒă§ăăȘい +* 侍捁戆ăȘăƒ‘ăƒŒăƒŸăƒƒă‚·ăƒ§ăƒł +* ăƒȘă‚œăƒŒă‚čăƒȘミットぼレンゾ +* ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăƒ©ăƒłă‚żă‚€ăƒ ăźèš­ćźšăźäžć‚™ + +こぼようăȘçŠ¶æłă‚’æ€œçŸ„ă™ă‚‹1぀たæ–čæł•ăšă—ăŠă€DeploymentたăƒȘă‚œăƒŒă‚čćźšçŸ©ă§ăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłăźăƒ‘ăƒ©ăƒĄăƒŒă‚żă‚’æŒ‡ćźšă—ăŸă™([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentăźæ›Žæ–°ăŒćœæ­ąă—ăŸă“ăšă‚’ç€șă™ć‰ă«Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒćŸ…ă€ç§’æ•°ă‚’ç€șă—ăŸă™ă€‚ + +äž‹èš˜ăź`kubectl`コマンドでăƒȘă‚œăƒŒă‚čćźšçŸ©ă«`progressDeadlineSeconds`ă‚’èš­ćźšă—ăŸă™ă€‚ă“ă‚ŒăŻDeploymentăźæ›Žæ–°ăŒæ­ąăŸăŁăŠă‹ă‚‰10ćˆ†ćŸŒă«ă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒć€±æ•—ă‚’é€šçŸ„ă•ă›ă‚‹ăŸă‚ă§ă™ă€‚ + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +deployment.apps/nginx-deployment patched +``` +侀ćșŠăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłă‚’è¶…éŽă™ă‚‹ăšă€Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻDeploymentた`.status.conditions`ă«äž‹èš˜ăźDeploymentConditionă‚’èżœćŠ ă—ăŸă™ă€‚ + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +ă‚čăƒ†ăƒŒă‚żă‚čăźçŠ¶æ…‹ă«é–ąă™ă‚‹ă•ă‚‰ăȘă‚‹æƒ…ć ±ăŻ[Kubernetes APIăźèŠć‰‡](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)を揂照しどください。 + +{{< note >}} +KubernetesăŻćœæ­ąçŠ¶æ…‹ăźDeploymentă«ćŻŸă—ăŠă€ă‚čăƒ†ăƒŒă‚żă‚čçŠ¶æ…‹ă‚’ć ±ć‘Šă™ă‚‹ä»„ć€–ăźă‚ąă‚Żă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă—ăŸă›ă‚“ă€‚é«˜ăƒŹăƒ™ăƒ«ăźă‚ȘăƒŒă‚±ă‚čăƒˆăƒŹăƒŒă‚żăƒŒăŻă“ă‚Œă‚’ćˆ©ç”šă—ăŠă€çŠ¶æ…‹ă«ćżœă˜ăŠèĄŒć‹•ă§ăăŸă™ă€‚äŸ‹ăˆă°ă€ć‰ăźăƒăƒŒă‚žăƒ§ăƒłăžăźDeploymentăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚ŻăŒæŒ™ă’ă‚‰ă‚ŒăŸă™ă€‚ +{{< /note >}} + +{{< note >}} +Deploymentă‚’ćœæ­ąă™ă‚‹ăšă€KubernetesăŻăƒŠăƒŒă‚¶ăƒŒăŒæŒ‡ćźšă—ăŸăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłă‚’è¶…ăˆăŸă‹ă©ă†ă‹ăƒă‚§ăƒƒă‚Żă—ăŸă›ă‚“ă€‚ăƒŠăƒŒă‚¶ăƒŒăŻăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźăšă‚†ă†ă§ă‚‚Deploymentă‚’ćź‰ć…šă«äž€æ™‚ćœæ­ąă§ăă€ăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłă‚’è¶…ăˆăŸă‚€ăƒ™ăƒłăƒˆă‚’ăƒˆăƒȘă‚ŹăƒŒă™ă‚‹ă“ăšăȘăć†é–‹ă§ăăŸă™ă€‚ +{{< /note >}} + +èš­ćźšă—ăŸă‚żă‚€ăƒ ă‚ąă‚Šăƒˆăźç§’æ•°ăŒć°ă•ă‹ăŁăŸă‚Šă€äž€æ™‚çš„ăȘă‚šăƒ©ăƒŒăšă—ăŠæ‰±ăˆă‚‹ä»–ăźçšźéĄžăźă‚šăƒ©ăƒŒăŒćŽŸć› ăšăȘり、Deploymentă§äž€æ™‚çš„ăȘă‚šăƒ©ăƒŒăŒć‡șă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚äŸ‹ăˆă°ă€ăƒȘă‚œăƒŒă‚čたć‰Čă‚Šćœ“ăŠăŒäžććˆ†ăȘć Žćˆă‚’è€ƒăˆăŸă™ă€‚Deploymentăźè©łçŽ°æƒ…ć ±ă‚’çąșèȘă™ă‚‹ăšă€äž‹èš˜ăźă‚»ă‚Żă‚·ăƒ§ăƒłăŒèĄšç€șă•ă‚ŒăŸă™ă€‚ + +```shell +kubectl describe deployment nginx-deployment +``` +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +`kubectl get deployment nginx-deployment -o yaml`ă‚’ćźŸèĄŒă™ă‚‹ăšă€Deploymentたă‚čăƒ†ăƒŒă‚żă‚čăŻäž‹èš˜ăźă‚ˆă†ă«ăȘă‚ŠăŸă™ă€‚ + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +æœ€ćŸŒă«ă€äž€ćșŠDeploymentăźæ›Žæ–°ć‡Šç†ăźăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłă‚’è¶Šăˆă‚‹ăšă€KubernetesはDeploymentたă‚čăƒ†ăƒŒă‚żă‚čずé€ČèĄŒäž­ăźçŠ¶æ…‹ă‚’æ›Žæ–°ă—ăŸă™ă€‚ + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Deploymentか他たăƒȘă‚œăƒŒă‚čă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă‚’èĄŒă†ă‹ă€äœżç”šă—ăŠă„ă‚‹ćć‰ç©ș間憅でăƒȘă‚œăƒŒă‚čたć‰Čă‚Šćœ“ăŠă‚’ćą—ă‚„ă™ă“ăšă§ă€ăƒȘă‚œăƒŒă‚čたć‰Čă‚Šćœ“ăŠäžè¶łăźć•éĄŒă«ćŻŸć‡Šă§ăăŸă™ă€‚ć‰Čă‚Šćœ“ăŠæĄä»¶ă‚’æș€ăŸă™ăšă€Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻDeploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’ćźŒäș†ă•ă›ă€Deploymentたă‚čăƒ†ăƒŒă‚żă‚čăŒæˆćŠŸçŠ¶æ…‹ă«ăȘるぼをçąșèȘă§ăăŸă™(`Status=True`ず`Reason=NewReplicaSetAvailable`)。 + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Status=True`た`Type=Available`は、DeploymentăŒæœ€ć°ćŻç”šæ€§ăźçŠ¶æ…‹ă§ă‚ă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™ă€‚æœ€ć°ćŻç”šæ€§ăŻă€Deploymentăźæ›Žæ–°æˆŠç•„ă«ăŠă„ăŠæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăƒ‘ăƒ©ăƒĄăƒŒă‚żă«ă‚ˆă‚Šæ±șćźšă•ă‚ŒăŸă™ă€‚`Status=True`た`Type=Progressing`は、Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆăźé€”äž­ă§ă€æ›Žæ–°ć‡Šç†ăŒé€ČèĄŒäž­ă§ă‚ă‚‹ă‹ă€æ›Žæ–°ć‡Šç†ăŒćźŒäș†ă—ă€ćż…èŠăȘæœ€ć°æ•°ăźăƒŹăƒ—ăƒȘă‚«ăŒćˆ©ç”šćŻèƒœă§ă‚ă‚‹ă“ăšă‚’æ„ć‘łă—ăŸă™(搄TypeたReason項盼をçąșèȘă—ăŠăă ă•ă„ă€‚ă“ăźă‚±ăƒŒă‚čでは、`Reason=NewReplicaSetAvailable`はDeploymentăźæ›Žæ–°ăŒćźŒäș†ă—ăŸă“ăšă‚’æ„ć‘łă—ăŸă™)。 + +`kubectl rollout status`ă‚’ćźŸèĄŒă—ăŠDeploymentăŒæ›Žæ–°ă«ć€±æ•—ă—ăŸă‹ă©ă†ă‹ă‚’çąșèȘă§ăăŸă™ă€‚`kubectl rollout status`はDeploymentăŒæ›Žæ–°ć‡Šç†ăźăƒ‡ăƒƒăƒ‰ăƒ©ă‚€ăƒłă‚’è¶…ăˆăŸăšăă«0仄怖た甂äș†ă‚łăƒŒăƒ‰ă‚’èż”ă—ăŸă™ă€‚ + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +ćźŸèĄŒç”æžœăŻäž‹èš˜ăźăšăŠă‚Šă§ă™ă€‚ +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### ć€±æ•—ă—ăŸDeploymentăźæ“äœœ + +æ›Žæ–°ćźŒäș†ă—ăŸDeploymentă«é©ç”šă—ăŸć…šăŠăźă‚ąă‚Żă‚·ăƒ§ăƒłăŻă€æ›Žæ–°ć€±æ•—ă—ăŸDeploymentă«ćŻŸă—ăŠă‚‚é©ç”šă•ă‚ŒăŸă™ă€‚ă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă€ă‚čă‚±ăƒŒăƒ«ăƒ€ă‚ŠăƒłăŒă§ăă€ć‰ăźăƒȘăƒ“ă‚žăƒ§ăƒłăžăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă‚„ă€Deploymentăźăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă«è€‡æ•°ăźæ›Žæ–°ă‚’é©ç”šă•ă›ă‚‹ćż…èŠăŒă‚ă‚‹ăšăăŻäž€æ™‚ćœæ­ąă‚‚ă§ăăŸă™ă€‚ + +## ć€ă„ăƒȘビゾョンぼクăƒȘăƒŒăƒłă‚ąăƒƒăƒ—ăƒăƒȘă‚·ăƒŒ {#clean-up-policy} + +DeploymentăŒçźĄç†ă™ă‚‹ć€ă„ReplicaSetă‚’ă„ăă€äżæŒă™ă‚‹ă‹ă‚’æŒ‡ćźšă™ă‚‹ăŸă‚ă«ă€`.spec.revisionHistoryLimit`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’èš­ćźšă§ăăŸă™ă€‚ă“ăźć€€ă‚’è¶…ăˆăŸć€ă„ReplicaSetăŻăƒăƒƒă‚Żă‚°ăƒ©ă‚Šăƒłăƒ‰ă§ă‚ŹăƒŒăƒ™ăƒŒă‚žă‚łăƒŹă‚Żă‚·ăƒ§ăƒłăźćŻŸè±ĄăšăȘăŁăŠć‰Šé™€ă•ă‚ŒăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻă“ăźć€€ăŻ10です。 + +{{< note >}} +ă“ăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’æ˜Žç€ș的に0ă«èš­ćźšă™ă‚‹ăšă€Deploymentăźć…šăŠăźć±„æ­Žă‚’ć‰Šé™€ă—ăŸă™ă€‚ćŸ“ăŁăŠă€DeploymentăŻăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă§ăăŸă›ă‚“ă€‚ +{{< /note >}} + +## ă‚«ăƒŠăƒȘă‚ąăƒ‘ă‚żăƒŒăƒłă«ă‚ˆă‚‹ăƒ‡ăƒ—ăƒ­ă‚€ + +Deploymentă‚’äœżăŁăŠäž€éƒšăźăƒŠăƒŒă‚¶ăƒŒă‚„ă‚”ăƒŒăƒăƒŒă«ćŻŸă—ăŠăƒȘăƒȘăƒŒă‚čăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’ă—ăŸă„ăšăă€[ăƒȘă‚œăƒŒă‚čぼ缡理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)ă«èš˜èŒ‰ă•ă‚ŒăŠă„ă‚‹ă‚«ăƒŠăƒȘă‚ąăƒ‘ă‚żăƒŒăƒłă«ćŸ“ăŁăŠă€ăƒȘăƒȘăƒŒă‚čæŻŽă«1ă€ăšă€ă€è€‡æ•°ăźDeploymentă‚’äœœæˆă§ăăŸă™ă€‚ + +## Deployment Specăźèš˜èż° + +他た慚おたKubernetesăźèš­ćźšăšćŒæ§˜ă«ă€Deploymentは`apiVersion`、`kind`や`metadata`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’ćż…èŠăšă—ăŸă™ă€‚èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ăźćˆ©ç”šă«é–ąă™ă‚‹æƒ…ć ±ăŻ[ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźăƒ‡ăƒ—ăƒ­ă‚€](/docs/tutorials/stateless-application/run-stateless-application-deployment/)ă‚’ć‚ç…§ă—ăŠăă ă•ă„ă€‚ă‚łăƒłăƒ†ăƒŠăƒŒăźèš­ćźšă«é–ąă—ăŠăŻ[ăƒȘă‚œăƒŒă‚čを缡理するためぼkubectlăźäœżç”š](/docs/concepts/overview/working-with-objects/object-management/)を揂照しどください。 + +Deploymentは[`.spec`ă‚»ă‚Żă‚·ăƒ§ăƒł](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)ă‚‚ćż…èŠăšă—ăŸă™ă€‚ + +### Podăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆ + +`.spec.template`ず`.spec.selector`は`.spec`ă«ăŠă‘ă‚‹ćż…é ˆăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă™ă€‚ + +`.spec.template`は[Podăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆ](/docs/concepts/workloads/pods/pod-overview/#pod-templates)です。これは.spec憅でネă‚čトされどいăȘいこべべ、`apiVersion`や`kind`ă‚’æŒăŸăȘいこずを陀いおは[Pod](/docs/concepts/workloads/pods/pod/)べ搌じă‚čă‚­ăƒŒăƒžăšăȘă‚ŠăŸă™ă€‚ + +Podăźćż…é ˆăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă«ćŠ ăˆăŠă€Deployment憅ぼPodăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă§ăŻé©ćˆ‡ăȘăƒ©ăƒ™ăƒ«ăšć†è”·ć‹•ăƒăƒȘă‚·ăƒŒă‚’èš­ćźšă—ăȘくどはăȘă‚ŠăŸă›ă‚“ă€‚ăƒ©ăƒ™ăƒ«ăŻä»–ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăšé‡è€‡ă—ăȘă„ă‚ˆă†ă«ă—ăŠăă ă•ă„ă€‚ăƒ©ăƒ™ăƒ«ă«ă€ă„ăŠăŻă€[ă‚»ăƒŹă‚Żă‚żăƒŒ](#selector)を揂照しどください。 + +[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`ă«ç­‰ă—ă„ăšăăźăżèš±ćŻă•ă‚ŒăŸă™ă€‚ă“ă‚ŒăŻăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă§æŒ‡ćźšă•ă‚ŒăŠă„ăȘă„ć Žćˆăźăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ă§ă™ă€‚ + +### レプăƒȘă‚«æ•° + +`.spec.replias`ăŻç†æƒłçš„ăȘPodăźæ•°ă‚’æŒ‡ćźšă™ă‚‹ă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăŻ1です。 + +### ă‚»ăƒŹă‚Żă‚żăƒŒ {#selector} + +`.spec.selector`ăŻćż…é ˆăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€Deploymentă«ă‚ˆăŁăŠćŻŸè±Ąăšă•ă‚Œă‚‹Podた[ăƒ©ăƒ™ăƒ«ă‚»ăƒŹă‚Żă‚żăƒŒ](/docs/concepts/overview/working-with-objects/labels/)ă‚’æŒ‡ćźšă—ăŸă™ă€‚ + +`.spec.selector`は`.spec.template.metadata.labels`ăšäž€è‡Žă—ăŠă„ă‚‹ćż…èŠăŒă‚ă‚Šă€äž€è‡Žă—ăȘい栮搈はAPIă«ă‚ˆăŁăŠæ‹’ćŠă•ă‚ŒăŸă™ă€‚ + +`apps/v1`ăƒăƒŒă‚žăƒ§ăƒłă«ăŠă„ăŠă€`.spec.selector`ず`.metadata.labels`ăŒæŒ‡ćźšă•ă‚ŒăŠă„ăȘい栮搈、`.spec.template.metadata.labels`ăźć€€ă«ćˆæœŸćŒ–ă•ă‚ŒăŸă›ă‚“ă€‚ăăźăŸă‚`.spec.selector`ず`.metadata.labels`ă‚’æ˜Žç€șçš„ă«æŒ‡ćźšă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ăŸăŸ`apps/v1`たDeploymentにおいお`.spec.selector`ăŻäœœæˆćŸŒă«äžć€‰ă«ăȘă‚ŠăŸă™ă€‚ + +Deploymentăźăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆăŒ`.spec.template`べ異ăȘる栮搈や、`.spec.replicas`ăźć€€ă‚’è¶…ăˆăŠPodăŒçšŒćƒă—ăŠă„ă‚‹ć Žćˆă€DeploymentăŻă‚»ăƒŹă‚Żă‚żăƒŒă«äž€è‡Žă™ă‚‹ăƒ©ăƒ™ăƒ«ă‚’æŒă€Podă‚’ć‰Šé™€ă—ăŸă™ă€‚Podăźæ•°ăŒç†æƒłçŠ¶æ…‹ă‚ˆă‚Šć°‘ăȘい栮搈Deploymentは`.spec.template`ă‚’ă‚‚ăšă«æ–°ă—ă„Podă‚’äœœæˆă—ăŸă™ă€‚ + +{{< note >}} +ăƒŠăƒŒă‚¶ăƒŒăŻă€Deploymentăźă‚»ăƒŹă‚Żă‚żăƒŒă«äž€è‡Žă™ă‚‹ăƒ©ăƒ™ăƒ«ă‚’æŒă€Podă‚’ă€ç›ŽæŽ„äœœæˆă—ăŸă‚Šä»–ăźDeploymentやReplicaSetやReplicationControlleră«ă‚ˆăŁăŠäœœæˆă™ă‚‹ăčăă§ăŻă‚ă‚ŠăŸă›ă‚“ă€‚äœœæˆă—ăŸć ŽćˆăŻæœ€ćˆăźDeploymentăŒă€ăƒ©ăƒ™ăƒ«ă«äž€è‡Žă™ă‚‹æ–°ă—ă„Podă‚’äœœæˆă—ăŸăšăżăȘă—ăŠă—ăŸă„ăŸă™ă€‚KubernetesăŻăƒŠăƒŒă‚¶ăƒŒăŒă“ă‚Œă‚’èĄŒăŁăŠă‚‚ă‚šăƒ©ăƒŒăȘどをć‡șă•ăšă€ć‡Šç†ă‚’æ­ąă‚ăŸă›ă‚“ă€‚ +{{< /note >}} + +ă‚»ăƒŹă‚Żă‚żăƒŒăŒé‡è€‡ă™ă‚‹è€‡æ•°ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’æŒă€ăšăă€ăăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻäș’ă„ă«ç«¶ćˆçŠ¶æ…‹ăšăȘă‚Šă€æ­Łă—ăă”ă‚‹ăŸă„ăŸă›ă‚“ă€‚ + +### 曎新戊畄 + +`.spec.strategy`ăŻć€ă„Podă‹ă‚‰æ–°ă—ă„Podă«çœźăæ›ăˆă‚‹éš›ăźæ›Žæ–°æˆŠç•„ă‚’æŒ‡ćźšă—ăŸă™ă€‚`.spec.strategy.type`は"Recreate"もしくは"RollingUpdate"ă‚’æŒ‡ćźšă§ăăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăŻ"RollingUpdate"です。 + +#### Deploymentăźć†äœœæˆ + +`.spec.strategy.type==Recreate`ăšæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăšăă€æ—ąć­˜ăźć…šăŠăźPodăŻæ–°ă—ă„PodăŒäœœæˆă•ă‚Œă‚‹ć‰ă«ć‰Šé™€ă•ă‚ŒăŸă™ă€‚ + +#### Deploymentăźăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆ + +`.spec.strategy.type==RollingUpdate`ăšæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăšăă€Deploymentは[ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆ](/docs/tasks/run-application/rolling-update-replication-controller/)ă«ă‚ˆă‚ŠPodă‚’æ›Žæ–°ă—ăŸă™ă€‚ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăźć‡Šç†ă‚’ă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ă™ă‚‹ăŸă‚ă«`maxUnavailable`ず`maxSurge`ă‚’æŒ‡ćźšă§ăăŸă™ă€‚ + +##### maxUnavailable + +`.spec.strategy.rollingUpdate.maxUnavailable`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€æ›Žæ–°ć‡Šç†ă«ăŠă„ăŠćˆ©ç”šäžćŻăšăȘă‚‹æœ€ć€§ăźPodæ•°ă‚’æŒ‡ćźšă—ăŸă™ă€‚ć€€ăŻç”¶ćŻŸć€€(䟋: 5)ă‚’æŒ‡ćźšă™ă‚‹ă‹ă€ç†æƒłçŠ¶æ…‹ăźPodăźăƒ‘ăƒŒă‚»ăƒłăƒ†ăƒŒă‚žă‚’æŒ‡ćźšă—ăŸă™(䟋: 10%)ă€‚ăƒ‘ăƒŒă‚»ăƒłăƒ†ăƒŒă‚žă‚’æŒ‡ćźšă—ăŸć Žćˆă€ç”¶ćŻŸć€€ăŻć°æ•°ćˆ‡ă‚ŠæšăŠă•ă‚ŒăŠèšˆçź—ă•ă‚ŒăŸă™ă€‚`.spec.strategy.rollingUpdate.maxSurge`が0ă«æŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ć Žćˆă€ă“ăźć€€ă‚’0ă«ă§ăăŸă›ă‚“ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻ25%です。 + +äŸ‹ăˆă°ă€ă“ăźć€€ăŒ30%ăšæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăšăă€ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăŒé–‹ć§‹ă™ă‚‹ăšć€ă„ReplicaSetăŻă™ăă«ç†æƒłçŠ¶æ…‹ăź70%にă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă‚ŒăŸă™ă€‚äž€ćșŠæ–°ă—いPodăŒçšŒćƒă§ăă‚‹çŠ¶æ…‹ă«ăȘă‚‹ăšă€ć€ă„ReplicaSetはさらにă‚čă‚±ăƒŒăƒ«ăƒ€ă‚Šăƒłă•ă‚Œă€ç¶šă„ăŠæ–°ă—ă„ReplicaSetがă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă‚ŒăŸă™ă€‚ă“ăźé–“ă€ćˆ©ç”šćŻèƒœăȘPodăźç·æ•°ăŻç†æƒłçŠ¶æ…‹ăźPodぼ民ăȘくべも70%仄䞊にăȘă‚‹ă‚ˆă†ă«äżèšŒă•ă‚ŒăŸă™ă€‚ + +##### maxSurge + +`.spec.strategy.rollingUpdate.maxSurge`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€ç†æƒłçŠ¶æ…‹ăźPodæ•°ă‚’è¶…ăˆăŠäœœæˆă§ăă‚‹æœ€ć€§ăźPodæ•°ă‚’æŒ‡ćźšă—ăŸă™ă€‚ć€€ăŻç”¶ćŻŸć€€(䟋: 5)ă‚’æŒ‡ćźšă™ă‚‹ă‹ă€ç†æƒłçŠ¶æ…‹ăźPodăźăƒ‘ăƒŒă‚»ăƒłăƒ†ăƒŒă‚žă‚’æŒ‡ćźšă—ăŸă™(䟋: 10%)ă€‚ăƒ‘ăƒŒă‚»ăƒłăƒ†ăƒŒă‚žă‚’æŒ‡ćźšă—ăŸć Žćˆă€ç”¶ćŻŸć€€ăŻć°æ•°ćˆ‡ă‚ŠäžŠă’ă§èšˆçź—ă•ă‚ŒăŸă™ă€‚`MaxUnavailable`が0ă«æŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ć Žćˆă€ă“ăźć€€ă‚’0ă«ă§ăăŸă›ă‚“ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻ25%です。 + +äŸ‹ăˆă°ă€ă“ăźć€€ăŒ30%ăšæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăšăă€ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăŒé–‹ć§‹ă™ă‚‹ăšæ–°ă—ă„ReplicaSetăŻă™ăă«æ›Žæ–°ă•ă‚ŒăŸă™ă€‚ă“ăźăšăć€ă„Podăšæ–°ă—ă„Podăźç·æ•°ăŻç†æƒłçŠ¶æ…‹ăź130%ă‚’è¶…ăˆăȘă„ă‚ˆă†ă«æ›Žæ–°ă•ă‚ŒăŸă™ă€‚äž€ćșŠć€ă„PodăŒć‰Šé™€ă•ă‚Œă‚‹ăšă€æ–°ă—ă„ReplicaSetはさらにă‚čă‚±ăƒŒăƒ«ă‚ąăƒƒăƒ—ă•ă‚ŒăŸă™ă€‚ă“ăźé–“ă€ćˆ©ç”šćŻèƒœăȘPodăźç·æ•°ăŻç†æƒłçŠ¶æ…‹ăźPodă«ćŻŸă—ăŠæœ€ć€§130%にăȘă‚‹ă‚ˆă†ă«äżèšŒă•ă‚ŒăŸă™ă€‚ + +### progressDeadlineSeconds + +`.spec.progressDeadlineSeconds`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€ă‚·ă‚čテムがDeploymentた[æ›Žæ–°ă«ć€±æ•—](#failed-deployment)ă—ăŸăšćˆ€æ–­ă™ă‚‹ăŸă§ă«ćŸ…ă€ç§’æ•°ă‚’æŒ‡ćźšă—ăŸă™ă€‚æ›Žæ–°ă«ć€±æ•—ă—ăŸăšćˆ€æ–­ă•ă‚ŒăŸăšăă€ăƒȘă‚œăƒŒă‚čたă‚čăƒ†ăƒŒă‚żă‚čは`Type=Progressing`、`Status=False`か぀`Reason=ProgressDeadlineExceeded`ずăȘるぼをçąșèȘă§ăăŸă™ă€‚Deploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻDeploymentăźæ›Žæ–°ăźăƒȘăƒˆăƒ©ă‚€ă—ç¶šă‘ăŸă™ă€‚ä»ŠćŸŒă€è‡Ș拕的ăȘăƒ­ăƒŒăƒ«ăƒăƒƒă‚ŻăŒćźŸèŁ…ă•ă‚ŒăŸăšăă€æ›Žæ–°ć€±æ•—çŠ¶æ…‹ă«ăȘるずすぐにDeploymentă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŒăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă‚’èĄŒă†ă‚ˆă†ă«ăȘă‚ŠăŸă™ă€‚ + +ă“ăźć€€ăŒæŒ‡ćźšă•ă‚ŒăŠă„ă‚‹ăšăă€`.spec.minReadySeconds`ă‚ˆă‚Šć€§ăă„ć€€ă‚’æŒ‡ćźšă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ + +### minReadySeconds {#min-ready-seconds} + +`.spec.minReadySeconds`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€æ–°ă—ăäœœæˆă•ă‚ŒăŸPodăŒćˆ©ç”šćŻèƒœăšăȘă‚‹ăŸă‚ă«ă€æœ€äœŽă©ă‚Œăă‚‰ă„ăźç§’æ•°ă‚łăƒłăƒ†ăƒŠăƒŒăŒă‚Żăƒ©ăƒƒă‚·ăƒ„ă™ă‚‹ă“ăšăȘăçšŒćƒă—ç¶šă‘ă‚Œă°ă‚ˆă„ă‹ă‚’æŒ‡ćźšă™ă‚‹ă‚‚ăźă§ă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻ0です(PodăŻäœœæˆă•ă‚Œă‚‹ăšă™ăă«ćˆ©ç”šćŻèƒœăšćˆ€æ–­ă•ă‚ŒăŸă™)。PodăŒćˆ©ç”šćŻèƒœăšćˆ€æ–­ă•ă‚ŒăŸć Žćˆă«ă€ă„ăŠă•ă‚‰ă«ć­Šă¶ăŸă‚ă«[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を揂照しどください。 + +### rollbackTo + +`.spec.rollbackTo`は、`extensions/v1beta1`ず`apps/v1beta1`たAPIăƒăƒŒă‚žăƒ§ăƒłă«ăŠă„ăŠéžæŽšć„šă§ă€`apps/v1beta2`ä»„é™ăźAPIăƒăƒŒă‚žăƒ§ăƒłă§ăŻă‚”ăƒăƒŒăƒˆă•ă‚ŒăŸă›ă‚“ă€‚ă‹ă‚ă‚Šă«ă€[才ぼăƒȘăƒ“ă‚žăƒ§ăƒłăžăźăƒ­ăƒŒăƒ«ăƒăƒƒă‚Ż](#rolling-back-to-a-previous-revision)でèȘŹæ˜Žă•ă‚ŒăŠă„ă‚‹ă‚ˆă†ă«`kubectl rollout undo`ă‚’äœżç”šă™ă‚‹ăčきです。 + +### ăƒȘăƒ“ă‚žăƒ§ăƒłć±„æ­ŽăźäżæŒäžŠé™ + +DeploymentたăƒȘăƒ“ă‚žăƒ§ăƒłć±„æ­ŽăŻă€Deploymentが缡理するReplicaSetă«äżæŒă•ă‚ŒăŠă„ăŸă™ă€‚ + +`.spec.revisionHistoryLimit`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă§ă€ăƒ­ăƒŒăƒ«ăƒăƒƒă‚ŻćŻèƒœăȘć€ă„ReplicaSetăźæ•°ă‚’æŒ‡ćźšă—ăŸă™ă€‚ă“ăźć€ă„ReplicaSetは`etcd`憅ぼăƒȘă‚œăƒŒă‚čă‚’æ¶ˆèȻし、`kubectl get rs`たć‡șćŠ›ç”æžœă‚’èŠ‹ă«ăăă—ăŸă™ă€‚Deploymentぼ搄ăƒȘăƒ“ă‚žăƒ§ăƒłăźèš­ćźšăŻReplicaSetă«äżæŒă•ă‚ŒăŸă™ă€‚ă“ăźăŸă‚äž€ćșŠć€ă„ReplicaSetăŒć‰Šé™€ă•ă‚Œă‚‹ăšă€ăăźăƒȘビゾョンぼDeploymentă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă™ă‚‹ă“ăšăŒă§ăăȘくăȘă‚ŠăŸă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻ10ă‚‚ăźć€ă„ReplicaSetăŒäżæŒă•ă‚ŒăŸă™ă€‚ă—ă‹ă—ă€ă“ăźć€€ăźæœ€é©ć€€ăŻæ–°ă—ă„Deploymnetăźæ›Žæ–°é »ćșŠăšćź‰ćźšæ€§ă«äŸć­˜ă—ăŸă™ă€‚ + +ă•ă‚‰ă«è©łă—ăèš€ă†ăšă€ă“ăźć€€ă‚’0にするず、0ぼレプăƒȘă‚«ă‚’æŒă€ć€ă„ć…šăŠăźReplicaSetăŒć‰Šé™€ă•ă‚ŒăŸă™ă€‚ă“ăźă‚±ăƒŒă‚čでは、ăƒȘăƒ“ă‚žăƒ§ăƒłć±„æ­ŽăŒćźŒć…šă«ć‰Šé™€ă•ă‚ŒăŠă„ă‚‹ăŸă‚æ–°ă—ă„Deploymentăźăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă‚’ćźŒäș†ă™ă‚‹ă“ăšăŒă§ăăŸă›ă‚“ă€‚ + +### paused + +`.spec.paused`はă‚Șăƒ—ă‚·ăƒ§ăƒłăźboolean怀で、Deploymentăźäž€æ™‚ćœæ­ąăšć†é–‹ăźăŸă‚ăźć€€ă§ă™ă€‚äž€æ™‚ćœæ­ąă•ă‚ŒăŠă„ă‚‹ă‚‚ăźăšă€ăă†ă§ăȘă„ă‚‚ăźăšăźé•ă„ăŻă€äž€æ™‚ćœæ­ąă•ă‚ŒăŠă„ă‚‹DeploymentはPodTemplateSpecぼいかăȘă‚‹ć€‰æ›ŽăŒă‚ăŁăŠă‚‚ăƒ­ăƒŒăƒ«ă‚ąă‚ŠăƒˆăŒăƒˆăƒȘă‚ŹăƒŒă•ă‚ŒăȘă„ă“ăšă§ă™ă€‚ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻDeploymentăŻäž€æ™‚ćœæ­ąă—ăŠă„ăȘă„çŠ¶æ…‹ă§äœœæˆă•ă‚ŒăŸă™ă€‚ + +## Deploymentăźä»Łæ›żæĄˆ +### kubectl rolling update + +[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)ă«ă‚ˆăŁăŠă€ćŒæ§˜ăźćœąćŒă§PodずReplicationControlleră‚’æ›Žæ–°ă§ăăŸă™ă€‚ă—ă‹ă—Deploymentăźäœżç”šăŒæŽšć„šă•ă‚ŒăŸă™ă€‚ăȘぜăȘらDeploymentăźäœœæˆăŻćźŁèš€çš„ă§ă‚ă‚Šă€ăƒ­ăƒŒăƒȘăƒłă‚°ă‚ąăƒƒăƒ—ăƒ‡ăƒŒăƒˆăŒæ›Žæ–°ă•ă‚ŒăŸćŸŒă«éŽćŽ»ăźăƒȘăƒ“ă‚žăƒ§ăƒłă«ăƒ­ăƒŒăƒ«ăƒăƒƒă‚Żă§ăă‚‹ăȘă©ă€ă„ăă€ă‹ăźèżœćŠ æ©ŸèƒœăŒă‚ă‚ŠăŸă™ă€‚ + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/_index.md b/content/ja/docs/concepts/workloads/pods/_index.md index a105f18fb3..7f62f167e8 100755 --- a/content/ja/docs/concepts/workloads/pods/_index.md +++ b/content/ja/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,4 @@ --- -title: "Pods" +title: "Pod" weight: 10 --- - diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 6fd5f321b5..9dde5bc7eb 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -91,7 +91,7 @@ spec: command: ['sh', '-c', 'echo The app is running! && sleep 3600'] ``` -ć€ă„ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłæ§‹æ–‡ăŒKubernetes1.6ず1.7ă«ăŠă„ăŠæœ‰ćŠčですが、1.6ă§ăŻæ–°ă—ă„æ§‹æ–‡ă«ă‚‚ćŻŸćżœă—ăŠă„ăŸă™ă€‚Kubernetes1.8ä»„é™ă§ăŻæ–°ă—ă„æ§‹æ–‡ăŻă‚’äœżç”šă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚KubernetesではInită‚łăƒłăƒ†ăƒŠăźćźŁèš€ă‚’`spec`ă«ç§»èĄŒă•ă›ăŸă—ăŸă€‚ +ć€ă„ă‚ąăƒŽăƒ†ăƒŒă‚·ăƒ§ăƒłæ§‹æ–‡ăŒKubernetes1.6ず1.7ă«ăŠă„ăŠæœ‰ćŠčですが、1.6ă§ăŻæ–°ă—ă„æ§‹æ–‡ă«ă‚‚ćŻŸćżœă—ăŠă„ăŸă™ă€‚Kubernetes1.8ä»„é™ă§ăŻæ–°ă—ă„æ§‹æ–‡ă‚’äœżç”šă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚KubernetesではInită‚łăƒłăƒ†ăƒŠăźćźŁèš€ă‚’`spec`ă«ç§»èĄŒă•ă›ăŸă—ăŸă€‚ ```yaml apiVersion: v1 diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index f46b8f2500..f1f48a57b6 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -17,11 +17,11 @@ card: {{% capture body %}} ## Podă«ă€ă„ăŠç†è§Łă™ă‚‹ -*Pod* は、KubernetesたćŸșæœŹçš„ăȘăƒ“ăƒ«ăƒ‡ă‚Łăƒłă‚°ăƒ–ăƒ­ăƒƒă‚ŻăšăȘă‚ŠăŸă™ă€‚Kubernetesă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăƒąăƒ‡ăƒ«ăźäž­ă§ă€ăƒŠăƒŒă‚¶ăƒŒăŒäœœæˆă—ă€ăƒ‡ăƒ—ăƒ­ă‚€ćŻèƒœăȘă‚·ăƒłăƒ—ăƒ«ă§æœ€ă‚‚æœ€ć°ăźăƒŠăƒ‹ăƒƒăƒˆă§ă™ă€‚ć˜äž€ăźPodăŻă‚Żăƒ©ă‚čă‚żăƒŒäžŠă§çšŒćƒă™ă‚‹ć˜äž€ăźăƒ—ăƒ­ă‚»ă‚čă‚’èĄšçŸă—ăŸă™ă€‚ +*Pod* は、KubernetesケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźćŸșæœŹçš„ăȘćźŸèĄŒć˜äœă§ă™ă€‚ă“ă‚ŒăŻă€äœœæˆăŸăŸăŻăƒ‡ăƒ—ăƒ­ă‚€ă™ă‚‹Kubernetesă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆăƒąăƒ‡ăƒ«ăźäž­ă§æœ€ć°ă‹ă€æœ€ă‚‚ć˜çŽ”ăȘć˜äœă§ă™ă€‚Podは、{{< glossary_tooltip term_id="cluster" >}}ă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ăƒ—ăƒ­ă‚»ă‚čă‚’èĄšă—ăŸă™ă€‚ -捘侀ぼPodは、ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚łăƒłăƒ†ăƒŠïŒˆă„ăă€ă‹ăźć Žćˆă«ăŠă„ăŠăŻè€‡æ•°ăźă‚łăƒłăƒ†ăƒŠïŒ‰ă‚„ă€ă‚čăƒˆăƒŹăƒŒă‚žăƒȘă‚œăƒŒă‚čă€ăƒŠăƒ‹ăƒŒă‚ŻăȘăƒăƒƒăƒˆăƒŻăƒŒă‚ŻIPă‚„ă€ă‚łăƒłăƒ†ăƒŠăŒă©ăźă‚ˆă†ă«çšŒćƒă™ăčăă‹ç”±ćˆ¶ă™ă‚‹ăŸă‚ăźă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’ă‚«ăƒ—ă‚»ăƒ«ćŒ–ă—ăŸă™ă€‚ć˜äž€ăźPodは、ある捘侀ぼDeploymentぼラニット(捘侀ぼコンテナもしくはăƒȘă‚œăƒŒă‚čă‚’ć…±æœ‰ă™ă‚‹ă€ćŻ†æŽ„ă«é€Łæșă•ă‚ŒăŸć°‘æ•°ăźă‚łăƒłăƒ†ăƒŠçŸ€ă‚’ć«ă‚€ă‚ˆă†ăȘ*Kubernetes憅でぼケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźć˜äž€ăźă‚€ăƒłă‚čタンă‚č*) ă‚’èĄšçŸă—ăŸă™ă€‚ +Podは、ケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźă‚łăƒłăƒ†ăƒŠ(ă„ăă€ă‹ăźć Žćˆă«ăŠă„ăŠăŻè€‡æ•°ăźă‚łăƒłăƒ†ăƒŠ)、ă‚čăƒˆăƒŹăƒŒă‚žăƒȘă‚œăƒŒă‚čă€ăƒŠăƒ‹ăƒŒă‚ŻăȘăƒăƒƒăƒˆăƒŻăƒŒă‚ŻIPă€ăŠă‚ˆăłă‚łăƒłăƒ†ăƒŠăźćźŸèĄŒæ–čæł•ă‚’çźĄç†ă™ă‚‹ă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’ă‚«ăƒ—ă‚»ăƒ«ćŒ–ă—ăŸă™ă€‚PodăŻăƒ‡ăƒ—ăƒ­ă‚€ăƒĄăƒłăƒˆăźć˜äœă€ă™ăȘわち*KubernetesぼケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźć˜äž€ă‚€ăƒłă‚čタンă‚č* で、捘侀ぼ{{< glossary_tooltip term_id="container" >}}ăŸăŸăŻćŻ†ç”ćˆăȘăƒȘă‚œăƒŒă‚čă‚’ć…±æœ‰ă™ă‚‹ć°‘æ•°ăźă‚łăƒłăƒ†ăƒŠă§æ§‹æˆă•ă‚Œă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ -> [Docker](https://www.docker.com)はKubernetesたPodć†…ă§äœżă‚ă‚Œă‚‹æœ€ă‚‚äž€èˆŹçš„ăȘă‚łăƒłăƒ†ăƒŠăƒ©ăƒłă‚żă‚€ăƒ ă§ă™ăŒă€PodăŻä»–ăźă‚łăƒłăƒ†ăƒŠăƒ©ăƒłă‚żă‚€ăƒ ă‚‚ćŒæ§˜ă«ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ +[Docker](https://www.docker.com)はKubernetesたPodć†…ă§äœżă‚ă‚Œă‚‹æœ€ă‚‚äž€èˆŹçš„ăȘă‚łăƒłăƒ†ăƒŠăƒ©ăƒłă‚żă‚€ăƒ ă§ă™ăŒă€Podは他た[ă‚łăƒłăƒ†ăƒŠăƒ©ăƒłă‚żă‚€ăƒ ](/ja/docs/setup/production-environment/container-runtimes/)ă‚‚ćŒæ§˜ă«ă‚”ăƒăƒŒăƒˆă—ăŠă„ăŸă™ă€‚ Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒć†…ă§ăźPodは2぀た䞻ăȘæ–čæł•ă§äœżă†ă“ăšăŒă§ăăŸă™ă€‚ @@ -30,11 +30,10 @@ Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒć†…ă§ăźPodは2぀た䞻ăȘæ–čæł•ă§äœżă†ă“ăšăŒă§ * **捔èȘżă—ăŠçšŒćƒă•ă›ă‚‹ćż…èŠăŒă‚ă‚‹è€‡æ•°ăźă‚łăƒłăƒ†ăƒŠă‚’çšŒćƒă•ă›ă‚‹Pod** : 捘侀ぼPodは、ăƒȘă‚œăƒŒă‚čă‚’ć…±æœ‰ă™ă‚‹ćż…èŠăŒă‚ă‚‹ă‚ˆă†ăȘă€ćŻ†æŽ„ă«é€Łæșă—ăŸè€‡æ•°ăźćŒă˜ç’°ćąƒă«ă‚ă‚‹ă‚łăƒłăƒ†ăƒŠă‹ă‚‰ăȘるケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ă‚«ăƒ—ă‚»ăƒ«ćŒ–ă™ă‚‹ă“ăšă‚‚ă§ăăŸă™ă€‚ ă“ă‚Œă‚‰ăźćŒă˜ç’°ćąƒă«ă‚ă‚‹ă‚łăƒłăƒ†ăƒŠçŸ€ăŻă€ă‚”ăƒŒăƒ“ă‚čăźç”ćˆćŠ›ăźćŒ·ă„ăƒŠăƒ‹ăƒƒăƒˆă‚’æ§‹æˆă™ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ -- 1ă€ăźă‚łăƒłăƒ†ăƒŠăŒă€ć…±æœ‰ă•ă‚ŒăŸăƒœăƒȘăƒ„ăƒŒăƒ ă‹ă‚‰ăƒ•ă‚Ąă‚€ăƒ«ă‚’ăƒ‘ăƒ–ăƒȘックăȘć Žæ‰€ă«é€äżĄă—ă€äž€æ–čでは戆ć‰Čされた*ă‚”ă‚€ăƒ‰ă‚«ăƒŒ* ă‚łăƒłăƒ†ăƒŠăŒăă‚Œă‚‰ăźăƒ•ă‚Ąă‚€ăƒ«ă‚’æ›Žæ–°ă—ăŸă™ă€‚ăăźPodはそれらぼコンテナべă‚čăƒˆăƒŹăƒŒă‚žăƒȘă‚œăƒŒă‚čă‚’ă€ć˜äž€ăźçźĄç†ćŻèƒœăȘă‚šăƒłăƒ†ă‚Łăƒ†ă‚Łăšă—ăŠăŸăšă‚ăŸă™ă€‚ -[Kubernetes Blog](http://kubernetes.io/blog)にお、PodăźăƒŠăƒŒă‚čă‚±ăƒŒă‚čă«é–ąă™ă‚‹ă„ăă€ă‹ăźèżœćŠ æƒ…ć ±ă‚’èŠ‹ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ -さらăȘă‚‹æƒ…ć ±ă‚’ćŸ—ăŸă„ć ŽćˆăŻă€äž‹èš˜ăźăƒšăƒŒă‚žă‚’ć‚ç…§ăă ă•ă„ă€‚ +[Kubernetes Blog](http://kubernetes.io/blog)にお、PodăźăƒŠăƒŒă‚čă‚±ăƒŒă‚čă«é–ąă™ă‚‹ă„ăă€ă‹ăźèżœćŠ æƒ…ć ±ă‚’èŠ‹ă‚‹ă“ăšăŒă§ăăŸă™ă€‚ă•ă‚‰ăȘă‚‹æƒ…ć ±ă‚’ćŸ—ăŸă„ć ŽćˆăŻă€äž‹èš˜ăźăƒšăƒŒă‚žă‚’ć‚ç…§ăă ă•ă„ă€‚ -* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) -* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) + * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) + * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) 搄Podは、侎えられたケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźć˜äž€ăźă‚€ăƒłă‚čタンă‚čă‚’çšŒćƒă™ă‚‹ăŸă‚ăźă‚‚ăźă§ă™ă€‚ă‚‚ă—ăƒŠăƒŒă‚¶ăƒŒăźă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’æ°Žćčłă«ă‚čă‚±ăƒŒăƒ«ă•ă›ăŸă„ć Žćˆ(䟋: è€‡æ•°ă‚€ăƒłă‚čタンă‚čă‚’çšŒćƒă•ă›ă‚‹)ă€è€‡æ•°ăźPodă‚’äœżă†ăčきです。1぀たPodăŻć„ă‚€ăƒłă‚čタンă‚čă«ćŻŸćżœă—ăŠă„ăŸă™ă€‚ Kubernetesă«ăŠă„ăŠă€ă“ă‚ŒăŻäž€èˆŹçš„ă«_レプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒł_ ăšć‘Œă°ă‚ŒăŸă™ă€‚ @@ -50,7 +49,6 @@ PodăŻć‡é›†æ€§ăźé«˜ă„ă‚”ăƒŒăƒ“ă‚čăźăƒŠăƒ‹ăƒƒăƒˆă‚’æ§‹æˆă™ă‚‹ă‚ˆă†ăȘ耇 ăƒŠăƒŒă‚¶ăƒŒăŻă€ă‚łăƒłăƒ†ăƒŠçŸ€ăŒćŻ†æŽ„ă«é€ŁæșするようăȘ、ç‰čćźšăźă‚€ăƒłă‚čタンă‚čă«ăŠă„ăŠăźăżă“ăźăƒ‘ă‚żăƒŒăƒłă‚’äœżç”šă™ă‚‹ăčきです。 äŸ‹ăˆă°ă€ăƒŠăƒŒă‚¶ăƒŒăŒć…±æœ‰ăƒœăƒȘăƒ„ăƒŒăƒ ć†…ă«ă‚ă‚‹ăƒ•ă‚Ąă‚€ăƒ«ç”šăźWebă‚”ăƒŒăƒăšă—ăŠçšŒćƒă™ă‚‹ă‚łăƒłăƒ†ăƒŠăšă€äž‹èš˜ăźăƒ€ă‚€ă‚ąă‚°ăƒ©ăƒ ă«ă‚ă‚‹ă‚ˆă†ăȘ、ăƒȘăƒąăƒŒăƒˆăźă‚œăƒŒă‚čă‹ă‚‰ăƒ•ă‚Ąă‚€ăƒ«ă‚’æ›Žæ–°ă™ă‚‹ă‚ˆă†ăȘ戆雱された*ă‚”ă‚€ăƒ‰ă‚«ăƒŒ* ă‚łăƒłăƒ†ăƒŠă‚’æŒăŁăŠă„ă‚‹ă‚ˆă†ăȘ栮搈です。 - {{< figure src="/images/docs/pod.svg" alt="Podăźăƒ€ă‚€ă‚ąă‚°ăƒ©ăƒ " width="50%" >}} Podは、Podă«ă‚ˆăŁăŠæ§‹æˆă•ă‚ŒăŸă‚łăƒłăƒ†ăƒŠçŸ€ăźăŸă‚ă«2çšźéĄžăźć…±æœ‰ăƒȘă‚œăƒŒă‚čă‚’æäŸ›ă—ăŸă™ă€‚ *ăƒăƒƒăƒˆăƒŻăƒŒă‚­ăƒłă‚°* ず*ă‚čăƒˆăƒŹăƒŒă‚ž* です。 @@ -61,24 +59,24 @@ Podは、Podă«ă‚ˆăŁăŠæ§‹æˆă•ă‚ŒăŸă‚łăƒłăƒ†ăƒŠçŸ€ăźăŸă‚ă«2皟饞た慱 #### ă‚čăƒˆăƒŹăƒŒă‚ž -捘侀ぼPodăŻć…±æœ‰ă•ă‚ŒăŸă‚čăƒˆăƒŹăƒŒă‚ž*ボăƒȘăƒ„ăƒŒăƒ * ăźă‚»ăƒƒăƒˆă‚’æŒ‡ćźšă§ăăŸă™ă€‚Podć†…ăźć…šăŠăźă‚łăƒłăƒ†ăƒŠăŻă€ăăźć…±æœ‰ă•ă‚ŒăŸăƒœăƒȘăƒ„ăƒŒăƒ ă«ă‚ąă‚Żă‚»ă‚čă§ăă€ă‚łăƒłăƒ†ăƒŠé–“ă§ăƒ‡ăƒŒă‚żă‚’ć…±æœ‰ă™ă‚‹ă“ăšă‚’ćŻèƒœă«ă—ăŸă™ă€‚ăƒœăƒȘăƒ„ăƒŒăƒ ă‚‚ăŸăŸă€ă‚‚ă—Pod憅ぼコンテナぼ1ă€ăŒć†è”·ć‹•ăŒćż…èŠă«ăȘăŁăŸć Žćˆă«ć‚™ăˆăŠă€ăƒ‡ăƒŒă‚żă‚’æ°žç¶šćŒ–ă§ăăŸă™ă€‚ +捘侀ぼPodăŻć…±æœ‰ă•ă‚ŒăŸă‚čăƒˆăƒŹăƒŒă‚ž{{< glossary_tooltip term_id="volume" >}}ăźă‚»ăƒƒăƒˆă‚’æŒ‡ćźšă§ăăŸă™ă€‚Podć†…ăźć…šăŠăźă‚łăƒłăƒ†ăƒŠăŻă€ăăźć…±æœ‰ă•ă‚ŒăŸăƒœăƒȘăƒ„ăƒŒăƒ ă«ă‚ąă‚Żă‚»ă‚čă§ăă€ă‚łăƒłăƒ†ăƒŠé–“ă§ăƒ‡ăƒŒă‚żă‚’ć…±æœ‰ă™ă‚‹ă“ăšă‚’ćŻèƒœă«ă—ăŸă™ă€‚ăƒœăƒȘăƒ„ăƒŒăƒ ă‚‚ăŸăŸă€ă‚‚ă—Pod憅ぼコンテナぼ1ă€ăŒć†è”·ć‹•ăŒćż…èŠă«ăȘăŁăŸć Žćˆă«ć‚™ăˆăŠă€ăƒ‡ăƒŒă‚żă‚’æ°žç¶šćŒ–ă§ăăŸă™ă€‚ 捘侀ぼPodć†…ă§ăźć…±æœ‰ă‚čăƒˆăƒŹăƒŒă‚žă‚’KubernetesăŒă©ă†ćźŸèŁ…ă—ăŠă„ă‚‹ă‹ă«ă€ă„ăŠăźă•ă‚‰ăȘă‚‹æƒ…ć ±ă«ă€ă„ăŠăŻă€[Volumes](/docs/concepts/storage/volumes/)を揂照しどください。 ## Podă‚’ćˆ©ç”šă™ă‚‹ ăƒŠăƒŒă‚¶ăƒŒăŻăŸă‚Œă«ă€Kubenetesć†…ă§ç‹Źç«‹ă—ăŸPodă‚’ç›ŽæŽ„äœœæˆă™ă‚‹ć ŽćˆăŒă‚ă‚ŠăŸă™(ă‚·ăƒłă‚°ăƒ«ăƒˆăƒłPodăȘど)。 -これはPodăŒæŻ”èŒƒçš„ă€äž€æ™‚çš„ăȘäœżă„æšăŠă‚šăƒłăƒ†ă‚Łăƒ†ă‚Łăšă—ăŠăƒ‡ă‚¶ă‚€ăƒłă•ă‚ŒăŠă„ă‚‹ăŸă‚ă§ă™ă€‚PodăŒäœœæˆă•ă‚ŒăŸæ™‚ïŒˆăƒŠăƒŒă‚¶ăƒŒă«ă‚ˆăŁăŠç›ŽæŽ„çš„ă€ăŸăŸăŻă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠé–“æŽ„çš„ă«äœœæˆă•ă‚ŒăŸć ŽćˆïŒ‰ă€ăƒŠăƒŒă‚¶ăƒŒăźă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźć˜äž€ăźNodeäžŠă§çšŒćƒă™ă‚‹ă‚ˆă†ă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°ă•ă‚ŒăŸă™ă€‚ăăźPodăŻăƒ—ăƒ­ă‚»ă‚čăŒćœæ­ąă•ă‚ŒăŸă‚Šă€Podă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŒć‰Šé™€ă•ă‚ŒăŸă‚Šă€PodがăƒȘă‚œăƒŒă‚čăźæŹ ćŠ‚ăźăŸă‚ă«*èżœă„ć‡șされ* たり、NodeăŒæ•…éšœă™ă‚‹ăŸă§NodeäžŠă«æź‹ă‚Šç¶šă‘ăŸă™ă€‚ +これはPodăŒæŻ”èŒƒçš„ă€äž€æ™‚çš„ăȘäœżă„æšăŠă‚šăƒłăƒ†ă‚Łăƒ†ă‚Łăšă—ăŠăƒ‡ă‚¶ă‚€ăƒłă•ă‚ŒăŠă„ă‚‹ăŸă‚ă§ă™ă€‚PodăŒäœœæˆă•ă‚ŒăŸæ™‚ïŒˆăƒŠăƒŒă‚¶ăƒŒă«ă‚ˆăŁăŠç›ŽæŽ„çš„ă€ăŸăŸăŻă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠé–“æŽ„çš„ă«äœœæˆă•ă‚ŒăŸć ŽćˆïŒ‰ă€ăƒŠăƒŒă‚¶ăƒŒăźă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźć˜äž€ăź{{< glossary_tooltip term_id="node" >}}äžŠă§çšŒćƒă™ă‚‹ă‚ˆă†ă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°ă•ă‚ŒăŸă™ă€‚ăăźPodăŻăƒ—ăƒ­ă‚»ă‚čăŒćœæ­ąă•ă‚ŒăŸă‚Šă€Podă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŒć‰Šé™€ă•ă‚ŒăŸă‚Šă€PodがăƒȘă‚œăƒŒă‚čăźæŹ ćŠ‚ăźăŸă‚ă«*èżœă„ć‡șされ* ăŸă‚Šă€ăƒŽăƒŒăƒ‰ăŒæ•…éšœă™ă‚‹ăŸă§ăƒŽăƒŒăƒ‰äžŠă«æź‹ă‚Šç¶šă‘ăŸă™ă€‚ {{< note >}} 捘侀ぼPodć†…ă§ăźă‚łăƒłăƒ†ăƒŠă‚’ć†è”·ć‹•ă™ă‚‹ă“ăšăšă€ăăźPodă‚’ć†è”·ć‹•ă™ă‚‹ă“ăšă‚’æ··ćŒă—ăȘいでください。Podはそれè‡Șäœ“ăŻćźŸèĄŒă•ă‚ŒăŸă›ă‚“ăŒă€ă‚łăƒłăƒ†ăƒŠăŒćźŸèĄŒă•ă‚Œă‚‹ç’°ćąƒă§ă‚ă‚Šă€ć‰Šé™€ă•ă‚Œă‚‹ăŸă§ć­˜ćœšă—ç¶šă‘ăŸă™ă€‚ {{< /note >}} -Podは、Podそれè‡Șäœ“ă«ă‚ˆăŁăŠè‡Șć·±äżźćŸ©ă—ăŸă›ă‚“ă€‚ă‚‚ă—ă€çšŒćƒă•ă‚ŒăŠă„ăȘいNode䞊にPodがă‚čă‚±ă‚žăƒ„ăƒŒăƒ«ă•ă‚ŒăŸć Žćˆă‚„ă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°æ“äœœè‡Șäœ“ăŒć€±æ•—ă—ăŸć Žćˆă€PodăŒć‰Šé™€ă•ă‚ŒăŸă™ă€‚ćŒæ§˜ă«ă€PodはăƒȘă‚œăƒŒă‚čăźæŹ ćŠ‚ă‚„ă€Nodeぼメンテナンă‚čă«ă‚ˆă‚‹èżœă„ć‡șă—ăŒă‚ăŁăŸć ŽćˆăŻăă“ă§ćœæ­ąă—ăŸă™ă€‚Kubernetesは*ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ* ăšć‘Œă°ă‚Œă‚‹é«˜ăƒŹăƒ™ăƒ«ăźæŠœè±ĄæŠ‚ćż”ă‚’äœżç”šă—ă€ăă‚ŒăŻæŻ”èŒƒçš„äœżă„æšăŠćŻèƒœăȘPodă‚€ăƒłă‚čタンă‚čăźçźĄç†ă‚’èĄŒă„ăŸă™ă€‚ +Podは、Podそれè‡Șäœ“ă«ă‚ˆăŁăŠè‡Șć·±äżźćŸ©ă—ăŸă›ă‚“ă€‚ă‚‚ă—ă€çšŒćƒă•ă‚ŒăŠă„ăȘă„ăƒŽăƒŒăƒ‰äžŠă«Podがă‚čă‚±ă‚žăƒ„ăƒŒăƒ«ă•ă‚ŒăŸć Žćˆă‚„ă€ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°æ“äœœè‡Șäœ“ăŒć€±æ•—ă—ăŸć Žćˆă€PodăŒć‰Šé™€ă•ă‚ŒăŸă™ă€‚ćŒæ§˜ă«ă€PodはăƒȘă‚œăƒŒă‚čăźæŹ ćŠ‚ă‚„ă€ăƒŽăƒŒăƒ‰ăźăƒĄăƒłăƒ†ăƒŠăƒłă‚čă«ă‚ˆă‚‹èżœă„ć‡șă—ăŒă‚ăŁăŸć ŽćˆăŻăă“ă§ćœæ­ąă—ăŸă™ă€‚Kubernetesは*ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ* ăšć‘Œă°ă‚Œă‚‹é«˜ăƒŹăƒ™ăƒ«ăźæŠœè±ĄæŠ‚ćż”ă‚’äœżç”šă—ă€ăă‚ŒăŻæŻ”èŒƒçš„äœżă„æšăŠćŻèƒœăȘPodă‚€ăƒłă‚čタンă‚čăźçźĄç†ă‚’èĄŒă„ăŸă™ă€‚ ă“ăźă‚ˆă†ă«ă€Podă‚’ç›ŽæŽ„äœżă†ăźăŻćŻèƒœă§ă™ăŒă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’äœżç”šă—ăŸPodを缡理するæ–čăŒă‚ˆă‚Šäž€èˆŹçš„ă§ă™ă€‚KubernetesがPodたă‚čă‚±ăƒŒăƒȘăƒłă‚°ăšäżźćŸ©æ©Ÿèƒœă‚’ćźŸçŸă™ă‚‹ăŸă‚ă«ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’ă©ăźă‚ˆă†ă«äœżă†ă‹ă«é–ąă™ă‚‹æƒ…ć ±ăŻ[Podăšă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ](#pods-and-controllers)を揂照しどください。 ### Podăšă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒ -ć˜äž€ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă€ăƒŠăƒŒă‚¶ăƒŒăźăŸă‚ă«è€‡æ•°ăźPodă‚’äœœæˆăƒ»çźĄç†ă—ă€ăƒŹăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă€ă‚Żăƒ©ă‚čă‚żăƒŒăźă‚čă‚łăƒŒăƒ—ć†…ă§è‡Șć·±äżźćŸ©ăźæ©Ÿèƒœă‚’ăƒăƒłăƒ‰ăƒȘăƒłă‚°ă—ăŸă™ă€‚äŸ‹ăˆă°ă€ă‚‚ă—NodeăŒæ•…éšœă—ăŸć Žćˆă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻç•°ăȘるNode䞊にPodă‚’çœźăæ›ăˆă‚‹ă‚ˆă†ă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘングするこべで、è‡Ș拕的にăƒȘăƒ—ăƒŹăƒŒă‚čćŻèƒœăšăȘă‚ŠăŸă™ă€‚ +ć˜äž€ăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻă€ăƒŠăƒŒă‚¶ăƒŒăźăŸă‚ă«è€‡æ•°ăźPodă‚’äœœæˆăƒ»çźĄç†ă—ă€ăƒŹăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚„ăƒ­ăƒŒăƒ«ă‚ąă‚Šăƒˆă€ă‚Żăƒ©ă‚čă‚żăƒŒăźă‚čă‚łăƒŒăƒ—ć†…ă§è‡Șć·±äżźćŸ©ăźæ©Ÿèƒœă‚’ăƒăƒłăƒ‰ăƒȘăƒłă‚°ă—ăŸă™ă€‚äŸ‹ăˆă°ă€ă‚‚ă—ăƒŽăƒŒăƒ‰ăŒæ•…éšœă—ăŸć Žćˆă€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăŻç•°ăȘă‚‹ăƒŽăƒŒăƒ‰äžŠă«Podă‚’çœźăæ›ăˆă‚‹ă‚ˆă†ă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘングするこべで、è‡Ș拕的にăƒȘăƒ—ăƒŹăƒŒă‚čćŻèƒœăšăȘă‚ŠăŸă™ă€‚ 1ă€ăŸăŸăŻăă‚Œä»„äžŠăźPodă‚’ć«ă‚€ă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒăźäŸ‹ăŻäž‹èš˜ăźé€šă‚Šă§ă™ă€‚ @@ -115,7 +113,8 @@ spec: {{% /capture %}} {{% capture whatsnext %}} -* PodăźæŒŻă‚‹èˆžă„ă«é–ąă—ăŠć­Šă¶ă«ăŻäž‹èš˜ă‚’ć‚ç…§ă—ăŠăă ă•ă„ă€‚ - * [Podăźćœæ­ą](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Podăźăƒ©ă‚€ăƒ•ă‚”ă‚€ă‚Żăƒ«](/docs/concepts/workloads/pods/pod-lifecycle/) +* [Pod](/ja/docs/concepts/workloads/pods/pod/)ă«ă€ă„ăŠæ›Žă«ć­ŠăłăŸă—ă‚‡ă† +* PodăźæŒŻă‚‹èˆžă„ă«é–ąă—ăŠć­Šă¶ă«ăŻäž‹èš˜ă‚’ć‚ç…§ă—ăŠăă ă•ă„ + * [Podăźćœæ­ą](/ja/docs/concepts/workloads/pods/pod/#podた甂äș†) + * [Podăźăƒ©ă‚€ăƒ•ă‚”ă‚€ă‚Żăƒ«](/ja/docs/concepts/workloads/pods/pod-lifecycle/) {{% /capture %}} diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index 25c9a1d73e..d5f8120dbd 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -1,6 +1,6 @@ --- title: ăƒȘファレンă‚č -linkTitle: "Reference" +linkTitle: "ăƒȘファレンă‚č" main_menu: true weight: 70 content_template: templates/concept @@ -14,15 +14,15 @@ content_template: templates/concept {{% capture body %}} -## API Reference +## APIăƒȘファレンă‚č * [Kubernetes API抂芁](/docs/reference/using-api/api-overview/) - Kubernetes APIăźæŠ‚èŠă§ă™ă€‚ * Kubernetes APIăƒăƒŒă‚žăƒ§ăƒł + * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) * [1.12](/docs/reference/generated/kubernetes-api/v1.12/) - * [1.11](/docs/reference/generated/kubernetes-api/v1.11/) ## APIă‚Żăƒ©ă‚€ă‚ąăƒłăƒˆăƒ©ă‚€ăƒ–ăƒ©ăƒȘăƒŒ @@ -47,8 +47,6 @@ content_template: templates/concept * [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesă«ćŒæą±ă•ă‚ŒăŸă€ă‚łă‚ąăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ«ăƒŒăƒ—ă‚’ćŸ‹ă‚èŸŒă‚€ăƒ‡ăƒŒăƒąăƒłă§ă™ă€‚ * [kube-proxy](/docs/admin/kube-proxy/) - 捘箔ăȘTCP/UDPă‚čトăƒȘăƒŒăƒ ăźăƒ•ă‚©ăƒŻăƒŒăƒ‡ă‚Łăƒłă‚°ă‚„ă€äž€é€Łăźăƒăƒƒă‚Żă‚šăƒłăƒ‰é–“ă§TCP/UDPăźăƒ©ă‚Šăƒłăƒ‰ăƒ­ăƒ“ăƒłă§ăźăƒ•ă‚©ăƒŻăƒŒăƒ‡ă‚Łăƒłă‚°ă‚’ćźŸèĄŒă§ăăŸă™ă€‚ * [kube-scheduler](/docs/admin/kube-scheduler/) - ćŻç”šæ€§ă€ăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čă€ăŠă‚ˆăłă‚­ăƒŁăƒ‘ă‚·ăƒ†ă‚Łă‚’çźĄç†ă™ă‚‹ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒă§ă™ă€‚ -* [federation-apiserver](/docs/admin/federation-apiserver/) - é€Łćˆă‚Żăƒ©ă‚čă‚żăƒŒăźăŸă‚ăźAPIă‚”ăƒŒăƒăƒŒă§ă™ă€‚ -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 連搈Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒă«ćŒæą±ă•ă‚ŒăŸă€ă‚łă‚ąăźă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ăƒ«ăƒŒăƒ—ă‚’ćŸ‹ă‚èŸŒă‚€ăƒ‡ăƒŒăƒąăƒłă§ă™ă€‚ ## èš­èšˆăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆ diff --git a/content/ja/docs/reference/command-line-tools-reference/_index.md b/content/ja/docs/reference/command-line-tools-reference/_index.md new file mode 100644 index 0000000000..89d64ce646 --- /dev/null +++ b/content/ja/docs/reference/command-line-tools-reference/_index.md @@ -0,0 +1,5 @@ +--- +title: ă‚łăƒžăƒłăƒ‰ăƒ©ă‚€ăƒłăƒ„ăƒŒăƒ«ăźăƒȘファレンă‚č +weight: 60 +toc-hide: true +--- diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index d97950f462..92fb9868df 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -6,17 +6,16 @@ content_template: templates/concept {{% capture overview %}} ă“ăźăƒšăƒŒă‚žă§ăŻçźĄç†è€…ăŒăă‚Œăžă‚ŒăźKubernetesă‚łăƒłăƒăƒŒăƒăƒłăƒˆă§æŒ‡ćźšă§ăă‚‹ă•ăŸă–ăŸăȘăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźæŠ‚èŠă«ă€ă„ăŠèȘŹæ˜Žă—ăŠă„ăŸă™ă€‚ + +ć„æ©Ÿèƒœă«ăŠă‘ă‚‹ă‚čăƒ†ăƒŒă‚žăźèȘŹæ˜Žă«ă€ă„おは、[æ©Ÿèƒœăźă‚čăƒ†ăƒŒă‚ž](#feature-stages)を揂照しどください。 {{% /capture %}} {{% capture body %}} - ## 抂芁 -ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăŻă‚ąăƒ«ăƒ•ă‚Ąæ©ŸèƒœăŸăŸăŻćźŸéš“çš„æ©Ÿèƒœă‚’èš˜èż°ă™ă‚‹key=valueăźăƒšă‚ąăźă‚»ăƒƒăƒˆă§ă™ă€‚ +ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăŻă‚ąăƒ«ăƒ•ă‚Ąæ©ŸèƒœăŸăŸăŻćźŸéš“çš„æ©Ÿèƒœă‚’èš˜èż°ă™ă‚‹key=valueăźăƒšă‚ąăźă‚»ăƒƒăƒˆă§ă™ă€‚çźĄç†è€…ăŻć„ă‚łăƒłăƒăƒŒăƒăƒłăƒˆă§`--feature-gates`ă‚łăƒžăƒłăƒ‰ăƒ©ă‚€ăƒłăƒ•ăƒ©ă‚°ă‚’äœżç”šă™ă‚‹ă“ăšă§æ©Ÿèƒœă‚’ă‚ȘăƒłăŸăŸăŻă‚Șăƒ•ă«ă§ăăŸă™ă€‚ -çźĄç†è€…ăŻć„ă‚łăƒłăƒăƒŒăƒăƒłăƒˆă§`--feature-gates`ă‚łăƒžăƒłăƒ‰ăƒ©ă‚€ăƒłăƒ•ăƒ©ă‚°ă‚’äœżç”šă™ă‚‹ă“ăšă§æ©Ÿèƒœă‚’ă‚ȘăƒłăŸăŸăŻă‚Șăƒ•ă«ă§ăăŸă™ă€‚ć„ă‚łăƒłăƒăƒŒăƒăƒłăƒˆăŻăă‚Œăžă‚Œăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆć›șæœ‰ăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźèš­ćźšă‚’ă‚”ăƒăƒŒăƒˆă—ăŸă™ă€‚ -すăčăŠăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźć…šăƒȘă‚čăƒˆă‚’èĄšç€șするには`-h`ăƒ•ăƒ©ă‚°ă‚’äœżç”šă—ăŸă™ă€‚ -kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ă‚‹ă«ăŻä»„äž‹ăźă‚ˆă†ă«ăƒȘă‚čăƒˆăźæ©Ÿèƒœăƒšă‚ąă‚’`--feature-gates`ăƒ•ăƒ©ă‚°ă‚’äœżç”šă—ăŠć‰Čă‚Šćœ“ăŠăŸă™ă€‚ +ć„ă‚łăƒłăƒăƒŒăƒăƒłăƒˆăŻăă‚Œăžă‚Œăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆć›șæœ‰ăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźèš­ćźšă‚’ă‚”ăƒăƒŒăƒˆă—ăŸă™ă€‚ă™ăčăŠăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźć…šăƒȘă‚čăƒˆă‚’èĄšç€șするには`-h`ăƒ•ăƒ©ă‚°ă‚’äœżç”šă—ăŸă™ă€‚kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ă‚‹ă«ăŻä»„äž‹ăźă‚ˆă†ă«ăƒȘă‚čăƒˆăźæ©Ÿèƒœăƒšă‚ąă‚’`--feature-gates`ăƒ•ăƒ©ă‚°ă‚’äœżç”šă—ăŠć‰Čă‚Šćœ“ăŠăŸă™ă€‚ ```shell --feature-gates="...,DynamicKubeletConfig=true" @@ -26,23 +25,24 @@ kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ - ă€Œć°Žć…„é–‹ć§‹ăƒăƒŒă‚žăƒ§ăƒłă€ćˆ—ăŻæ©ŸèƒœăŒć°Žć…„ă•ă‚ŒăŸăšăă€ăŸăŸăŻăƒȘăƒȘăƒŒă‚čæź”éšŽăŒć€‰æ›Žă•ă‚ŒăŸăšăăźKubernetesăƒȘăƒȘăƒŒă‚čăƒăƒŒă‚žăƒ§ăƒłăšăȘă‚ŠăŸă™ă€‚ - ă€Œæœ€ç”‚ćˆ©ç”šćŻèƒœăƒăƒŒă‚žăƒ§ăƒłă€ćˆ—ăŻç©șではăȘă„ć ŽćˆăŻăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’äœżç”šă§ăă‚‹æœ€ćŸŒăźKubernetesăƒȘăƒȘăƒŒă‚čăƒăƒŒă‚žăƒ§ăƒłăšăȘă‚ŠăŸă™ă€‚ +- ă‚ąăƒ«ăƒ•ă‚ĄăŸăŸăŻăƒ™ăƒŒă‚żçŠ¶æ…‹ăźæ©ŸèƒœăŻ[AlphaăŸăŸăŻBetaăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ](#feature-gates-for-alpha-or-beta-features)ă«èŒ‰ăŁăŠă„ăŸă™ă€‚ +- ćź‰ćźšă—ăŠă„ă‚‹æ©ŸèƒœăŻă€[graduatedăŸăŸăŻdeprecatedăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ](#feature-gates-for-graduated-or-deprecated-features)ă«èŒ‰ăŁăŠă„ăŸă™ă€‚ +- graduatedăŸăŸăŻdeprecatedăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă«ăŻă€éžæŽšć„šăŠă‚ˆăłć»ƒæ­ąă•ă‚ŒăŸæ©Ÿèƒœă‚‚ăƒȘă‚čăƒˆă•ă‚ŒăŠă„ăŸă™ă€‚ + +### AlphaăŸăŸăŻBetaăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ {#feature-gates-for-alpha-or-beta-features} + +{{< table caption="AlphaăŸăŸăŻBetaăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ" >}} | æ©Ÿèƒœć | ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ | ă‚čăƒ†ăƒŒă‚ž | ć°Žć…„é–‹ć§‹ăƒăƒŒă‚žăƒ§ăƒł | æœ€ç”‚ćˆ©ç”šćŻèƒœăƒăƒŒă‚žăƒ§ăƒł | |---------|---------|-------|-------|-------| -| `Accelerators` | `false` | Alpha | 1.6 | 1.10 | -| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 | -| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 | -| `AdvancedAuditing` | `true` | GA | 1.12 | - | -| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 | -| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 | -| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | | | `AppArmor` | `true` | Beta | 1.4 | | | `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 | | `AttachVolumeLimit` | `true` | Beta | 1.12 | | -| `BlockVolume` | `false` | Alpha | 1.9 | | +| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | +| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | | `BlockVolume` | `true` | Beta | 1.13 | - | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | @@ -53,7 +53,8 @@ kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ | `CSIBlockVolume` | `true` | Beta | 1.14 | | | `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | | `CSIDriverRegistry` | `true` | Beta | 1.14 | | -| `CSIInlineVolume` | `false` | Alpha | 1.15 | - | +| `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 | +| `CSIInlineVolume` | `true` | Beta | 1.16 | - | | `CSIMigration` | `false` | Alpha | 1.14 | | | `CSIMigrationAWS` | `false` | Alpha | 1.14 | | | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | | @@ -62,99 +63,67 @@ kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | | | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 | | `CSINodeInfo` | `true` | Beta | 1.14 | | -| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 | -| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 | -| `CSIPersistentVolume` | `true` | GA | 1.13 | - | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | -| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 | -| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 | -| `CustomPodDNS` | `true` | GA | 1.14 | - | -| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 | -| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | | -| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 | -| `CustomResourceSubresources` | `true` | Beta | 1.11 | - | -| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 | -| `CustomResourceValidation` | `true` | Beta | 1.9 | | -| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 | -| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | | -| `DebugContainers` | `false` | Alpha | 1.10 | | +| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 | +| `CustomResourceDefaulting` | `true` | Beta | 1.16 | | | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 | | `DevicePlugins` | `true` | Beta | 1.10 | | +| `DryRun` | `false` | Alpha | 1.12 | 1.12 | | `DryRun` | `true` | Beta | 1.13 | | | `DynamicAuditing` | `false` | Alpha | 1.13 | | | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 | | `DynamicKubeletConfig` | `true` | Beta | 1.11 | | -| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 | -| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 | -| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | | -| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | | -| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | | +| `EndpointSlice` | `false` | Alpha | 1.16 | | +| `EphemeralContainers` | `false` | Alpha | 1.16 | | +| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 | +| `ExpandCSIVolumes` | `true` | Beta | 1.16 | | | `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 | | `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | | | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | | -| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | | -| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 | -| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | -| `HugePages` | `false` | Alpha | 1.8 | 1.9 | -| `HugePages` | `true` | Beta| 1.10 | 1.13 | -| `HugePages` | `true` | GA | 1.14 | | +| `EvenPodsSpread` | `false` | Alpha | 1.16 | | +| `HPAScaleToZero` | `false` | Alpha | 1.16 | | | `HyperVContainer` | `false` | Alpha | 1.10 | | -| `Initializers` | `false` | Alpha | 1.7 | 1.13 | -| `Initializers` | - | Deprecated | 1.14 | | -| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 | -| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 | -| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 | -| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | +| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | | | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 | -| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | | -| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | | +| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | | | `MountContainers` | `false` | Alpha | 1.9 | | -| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 | -| `MountPropagation` | `true` | Beta | 1.10 | 1.11 | -| `MountPropagation` | `true` | GA | 1.12 | | +| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | | `NodeLease` | `false` | Alpha | 1.12 | 1.13 | | `NodeLease` | `true` | Beta | 1.14 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | | -| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 | -| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 | -| `PersistentLocalVolumes` | `true` | GA | 1.14 | | -| `PodPriority` | `false` | Alpha | 1.8 | 1.10 | -| `PodPriority` | `true` | Beta | 1.11 | 1.13 | -| `PodPriority` | `true` | GA | 1.14 | | -| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 | -| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 | -| `PodReadinessGates` | `true` | GA | 1.14 | - | -| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | | +| `PodOverhead` | `false` | Alpha | 1.16 | - | +| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 | | `PodShareProcessNamespace` | `true` | Beta | 1.12 | | | `ProcMountType` | `false` | Alpha | 1.12 | | -| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 | +| `QOSReserved` | `false` | Alpha | 1.11 | | | `RemainingItemCount` | `false` | Alpha | 1.15 | | -| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | | | `RequestManagement` | `false` | Alpha | 1.15 | | +| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | | | `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | | | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | | | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | | | `RunAsGroup` | `true` | Beta | 1.14 | | +| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 | | `RuntimeClass` | `true` | Beta | 1.14 | | +| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | | | `SCTPSupport` | `false` | Alpha | 1.12 | | -| `ServerSideApply` | `false` | Alpha | 1.14 | | +| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | +| `ServerSideApply` | `true` | Beta | 1.16 | | | `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | | -| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 | -| `StorageObjectInUseProtection` | `true` | GA | 1.11 | | +| `StartupProbe` | `false` | Alpha | 1.16 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | -| `StreamingProxyRedirects` | `true` | Beta | 1.5 | | -| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 | -| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 | -| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 | -| `SupportIPVSProxyMode` | `true` | GA | 1.11 | | +| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | +| `StreamingProxyRedirects` | `true` | Beta | 1.6 | | | `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 | | `SupportNodePidsLimit` | `true` | Beta | 1.15 | | | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 | @@ -169,24 +138,106 @@ kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | Beta | 1.12 | | | `TTLAfterFinished` | `false` | Alpha | 1.12 | | -| `VolumePVCDataSource` | `false` | Alpha | 1.15 | | -| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | -| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | -| `VolumeScheduling` | `true` | GA | 1.13 | | +| `TopologyManager` | `false` | Alpha | 1.16 | | +| `ValidateProxyRedirects` | `false` | Alpha | 1.10 | 1.13 | +| `ValidateProxyRedirects` | `true` | Beta | 1.14 | | +| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | Beta | 1.16 | | | `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 | | `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | | | `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - | -| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 | -| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | | -| `WatchBookmark` | `false` | Alpha | 1.15 | | +| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 | +| `WatchBookmark` | `true` | Beta | 1.16 | | | `WindowsGMSA` | `false` | Alpha | 1.14 | | +| `WindowsGMSA` | `true` | Beta | 1.16 | | +| `WinDSR` | `false` | Alpha | 1.14 | | +| `WinOverlay` | `false` | Alpha | 1.14 | | +{{< /table >}} + +### GraduatedăŸăŸăŻDeprecatedăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ {#feature-gates-for-graduated-or-deprecated-features} + +{{< table caption="GraduatedăŸăŸăŻDeprecatedăźăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆ" >}} + +| æ©Ÿèƒœć | ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ | ă‚čăƒ†ăƒŒă‚ž | ć°Žć…„é–‹ć§‹ăƒăƒŒă‚žăƒ§ăƒł | æœ€ç”‚ćˆ©ç”šćŻèƒœăƒăƒŒă‚žăƒ§ăƒł | +|---------|---------|-------|-------|-------| +| `Accelerators` | `false` | Alpha | 1.6 | 1.10 | +| `Accelerators` | - | Deprecated | 1.11 | - | +| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 | +| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 | +| `AdvancedAuditing` | `true` | GA | 1.12 | - | +| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 | +| `AffinityInAnnotations` | - | Deprecated | 1.8 | - | +| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 | +| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 | +| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 | +| `CSIPersistentVolume` | `true` | GA | 1.13 | - | +| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 | +| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 | +| `CustomPodDNS` | `true` | GA | 1.14 | - | +| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 | +| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | 1.15 | +| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - | +| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.10 | +| `CustomResourceSubresources` | `true` | Beta | 1.11 | 1.15 | +| `CustomResourceSubresources` | `true` | GA | 1.16 | - | +| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 | +| `CustomResourceValidation` | `true` | Beta | 1.9 | 1.15 | +| `CustomResourceValidation` | `true` | GA | 1.16 | - | +| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 | +| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | 1.15 | +| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 | +| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | +| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 | +| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 | +| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | +| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 | +| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - | +| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 | +| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | +| `HugePages` | `false` | Alpha | 1.8 | 1.9 | +| `HugePages` | `true` | Beta| 1.10 | 1.13 | +| `HugePages` | `true` | GA | 1.14 | - | +| `Initializers` | `false` | Alpha | 1.7 | 1.13 | +| `Initializers` | - | Deprecated | 1.14 | - | +| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 | +| `KubeletConfigFile` | - | Deprecated | 1.10 | - | +| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 | +| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 | +| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | +| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 | +| `MountPropagation` | `true` | Beta | 1.10 | 1.11 | +| `MountPropagation` | `true` | GA | 1.12 | - | +| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 | +| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 | +| `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodPriority` | `false` | Alpha | 1.8 | 1.10 | +| `PodPriority` | `true` | Beta | 1.11 | 1.13 | +| `PodPriority` | `true` | GA | 1.14 | - | +| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 | +| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 | +| `PodReadinessGates` | `true` | GA | 1.14 | - | +| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 | +| `PVCProtection` | - | Deprecated | 1.10 | - | +| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 | +| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | +| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 | +| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 | +| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 | +| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | +| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | - | +| `VolumeSubpath` | `true` | GA | 1.13 | - | +{{< /table >}} ## æ©Ÿèƒœă‚’äœżç”šă™ă‚‹ -### 機胜ă‚čăƒ†ăƒŒă‚ž +### æ©Ÿèƒœăźă‚čăƒ†ăƒŒă‚ž {#feature-stages} -æ©Ÿèƒœă«ăŻ *Alpha* 、 *Beta* 、 *GA* ăźæź”éšŽăŒă‚ă‚ŠăŸă™ă€‚ -*Alpha* æ©ŸèƒœăšăŻïŒš +æ©Ÿèƒœă«ăŻ*Alpha* 、*Beta* 、*GA* ăźæź”éšŽăŒă‚ă‚ŠăŸă™ă€‚*Alpha* æ©ŸèƒœăšăŻïŒš * ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆă§ăŻç„ĄćŠčにăȘăŁăŠă„ăŸă™ă€‚ * ăƒă‚°ăŒă‚ă‚‹ă‹ă‚‚ă—ă‚ŒăŸă›ă‚“ă€‚æ©Ÿèƒœă‚’æœ‰ćŠčă«ă™ă‚‹ăšăƒă‚°ăŒç™șç”Ÿă™ă‚‹ćŻèƒœæ€§ăŒă‚ă‚ŠăŸă™ă€‚ @@ -207,8 +258,9 @@ kubeletăȘă©ăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă«ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆă‚’èš­ćźšă™ GAにăȘっどからさらăȘă‚‹ć€‰æ›Žă‚’ćŠ ăˆă‚‹ă“ăšăŻçŸćźŸçš„ă§ăŻăȘă„ć ŽćˆăŒă‚ă‚ŠăŸă™ă€‚ {{< /note >}} -*GA* æ©ŸèƒœăšăŻ(*GA* æ©ŸèƒœăŻ *漉漚版* æ©Ÿèƒœăšă‚‚ć‘Œă°ă‚ŒăŸă™): +*GA* æ©ŸèƒœăšăŻ(*GA* æ©ŸèƒœăŻ*漉漚版* æ©Ÿèƒœăšă‚‚ć‘Œă°ă‚ŒăŸă™): +* æ©ŸèƒœăŻćžžă«æœ‰ćŠčずăȘり、無ćŠčă«ă™ă‚‹ă“ăšăŻă§ăăŸă›ă‚“ă€‚ * ăƒ•ă‚ŁăƒŒăƒăƒŁăƒŒă‚ČăƒŒăƒˆăźèš­ćźšăŻäžèŠă«ăȘă‚ŠăŸă™ă€‚ * æ©Ÿèƒœăźćź‰ćźšç‰ˆăŻćŸŒç¶šăƒăƒŒă‚žăƒ§ăƒłă§ăƒȘăƒȘăƒŒă‚čă•ă‚ŒăŸă‚œăƒ•ăƒˆă‚Šă‚§ă‚ąă§äœżç”šă•ă‚ŒăŸă™ă€‚ @@ -224,6 +276,7 @@ GAにăȘっどからさらăȘă‚‹ć€‰æ›Žă‚’ćŠ ăˆă‚‹ă“ăšăŻçŸćźŸçš„ă§ăŻăȘい - `APIResponseCompression`:`LIST`や`GET`ăƒȘクスă‚čトたAPIハă‚čポンă‚čă‚’ćœ§çžźă—ăŸă™ă€‚ - `AppArmor`: Dockeră‚’äœżç”šă™ă‚‹ć Žćˆă«LinuxăƒŽăƒŒăƒ‰ă§AppArmoră«ă‚ˆă‚‹ćŒ·ćˆ¶ă‚ąă‚Żă‚»ă‚čă‚łăƒłăƒˆăƒ­ăƒŒăƒ«ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[AppArmorăƒăƒ„ăƒŒăƒˆăƒȘă‚ąăƒ«](/docs/tutorials/clusters/apparmor/)でçąșèȘă§ăăŸă™ă€‚ - `AttachVolumeLimit`: ボăƒȘăƒ„ăƒŒăƒ ăƒ—ăƒ©ă‚°ă‚€ăƒłă‚’æœ‰ćŠčă«ă™ă‚‹ă“ăšă§ăƒŽăƒŒăƒ‰ă«ă‚ąă‚żăƒƒăƒă§ăă‚‹ăƒœăƒȘăƒ„ăƒŒăƒ æ•°ăźćˆ¶é™ă‚’èš­ćźšă§ăăŸă™ă€‚ +- `BalanceAttachedNodeVolumes`: ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°äž­ă«ăƒăƒ©ăƒłă‚čぼべれたăƒȘă‚œăƒŒă‚čć‰Čă‚Šćœ“ăŠă‚’è€ƒæ…źă™ă‚‹ăƒŽăƒŒăƒ‰ăźăƒœăƒȘăƒ„ăƒŒăƒ ă‚«ă‚Šăƒłăƒˆă‚’ć«ă‚ăŸă™ă€‚ćˆ€æ–­ă‚’èĄŒă†éš›ă«ă€CPU、メヱăƒȘăƒŒäœżç”šçŽ‡ă€ăŠă‚ˆăłăƒœăƒȘăƒ„ăƒŒăƒ ă‚«ă‚ŠăƒłăƒˆăŒèż‘ă„ăƒŽăƒŒăƒ‰ăŒă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒă«ă‚ˆăŁăŠć„Șć…ˆă•ă‚ŒăŸă™ă€‚ - `BlockVolume`: PodでRawăƒ–ăƒ­ăƒƒă‚Żăƒ‡ăƒă‚€ă‚čăźćźšçŸ©ăšäœżç”šă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[RawブロックボăƒȘăƒ„ăƒŒăƒ ăźă‚”ăƒăƒŒăƒˆ](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)でçąșèȘă§ăăŸă™ă€‚ - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionă«ă‚ˆăŁăŠæ§‹æˆă•ă‚Œă‚‹èšˆç”»ăƒœăƒȘăƒ„ăƒŒăƒ ă‚’äœżç”šă™ă‚‹ă«ăŻServiceAccountボăƒȘăƒ„ăƒŒăƒ ă‚’ç§»èĄŒă—ăŸă™ă€‚è©łçŽ°ăŻ[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)でçąșèȘă§ăăŸă™ă€‚ - `CPUManager`: ă‚łăƒłăƒ†ăƒŠăƒŹăƒ™ăƒ«ăźCPUă‚ąăƒ•ă‚Łăƒ‹ăƒ†ă‚Łă‚”ăƒăƒŒăƒˆă‚’æœ‰ćŠčă—ăŸă™ă€‚[CPUマネゾメントポăƒȘă‚·ăƒŒ](/docs/tasks/administer-cluster/cpu-management-policies/)ă‚’èŠ‹ăŠăă ă•ă„ă€‚ @@ -242,39 +295,49 @@ GAにăȘっどからさらăȘă‚‹ć€‰æ›Žă‚’ćŠ ăˆă‚‹ă“ăšăŻçŸćźŸçš„ă§ăŻăȘい è©łçŽ°ă«ă€ă„ăŠăŻ[`csi`ボăƒȘăƒ„ăƒŒăƒ ă‚żă‚€ăƒ—](/docs/concepts/storage/volumes/#csi)ăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’çąșèȘă—ăŠăă ă•ă„ă€‚ - `CustomCPUCFSQuotaPeriod`: ăƒŽăƒŒăƒ‰ăŒCPUCFSQuotaPeriodă‚’ć€‰æ›Žă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `CustomPodDNS`: `dnsConfig`ăƒ—ăƒ­ăƒ‘ăƒ†ă‚Łă‚’äœżç”šă—ăŸPodたDNSèš­ćźšăźă‚«ă‚čă‚żăƒžă‚€ă‚șă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[PodたDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)でçąșèȘă§ăăŸă™ă€‚ +- `CustomResourceDefaulting`: OpenAPI v3バăƒȘăƒ‡ăƒŒă‚·ăƒ§ăƒłă‚čă‚­ăƒŒăƒžă«ăŠă„ăŠă€ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆć€€ăźCRDă‚”ăƒăƒŒăƒˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `CustomResourcePublishOpenAPI`: CRDたOpenAPIä»•æ§˜ă§ăźć…Źé–‹ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)ă‹ă‚‰äœœæˆă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čた`/status`および`/scale`ă‚”ăƒ–ăƒȘă‚œăƒŒă‚čă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ -- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)ă‹ă‚‰äœœæˆă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čたă‚čă‚­ăƒŒăƒžă«ă‚ˆă‚‹æ€œèšŒă‚’æœ‰ćŠčにする。 +- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)ă‹ă‚‰äœœæˆă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čたă‚čă‚­ăƒŒăƒžă«ă‚ˆă‚‹æ€œèšŒă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)ă‹ă‚‰äœœæˆă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čたWebhookăƒ™ăƒŒă‚čăźć€‰æ›ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ -- `DebugContainers`: PodăźăƒăƒŒăƒ ă‚čăƒšăƒŒă‚čă§ă€Œăƒ‡ăƒăƒƒă‚°ă€ă‚łăƒłăƒ†ăƒŠă‚’ćźŸèĄŒă§ăă‚‹ă‚ˆă†ă«ă—ăŠćźŸèĄŒäž­ăźPodăźăƒˆăƒ©ăƒ–ăƒ«ă‚·ăƒ„ăƒŒăƒ†ă‚Łăƒłă‚°ă‚’èĄŒă„ăŸă™ă€‚ - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)ă«ă‚ˆă‚‹ăƒŽăƒŒăƒ‰ă§ăźăƒȘă‚œăƒŒă‚čăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `DryRun`: ă‚”ăƒŒăƒăƒŒă‚”ă‚€ăƒ‰ă§ăź[dry run](/docs/reference/using-api/api-concepts/#dry-run)ăƒȘクスă‚čăƒˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `DynamicAuditing`: [ć‹•çš„ç›ŁæŸ»](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `DynamicKubeletConfig`: kubeletăźć‹•çš„æ§‹æˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚[kubeletăźć†èš­ćźš](/docs/tasks/administer-cluster/reconfigure-kubelet/)を揂照しどください。 - `DynamicProvisioningScheduling`: ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒă‚’æ‹ĄćŒ”ă—ăŠăƒœăƒȘăƒ„ăƒŒăƒ ăƒˆăƒăƒ­ă‚žăƒŒă‚’èȘè­˜ă—PVăƒ—ăƒ­ăƒ“ă‚žăƒ§ăƒ‹ăƒłă‚°ă‚’ć‡Šç†ă—ăŸă™ă€‚ă“ăźæ©ŸèƒœăŻă€v1.12た`VolumeScheduling`æ©Ÿèƒœă«ćźŒć…šă«çœźăæ›ăˆă‚‰ă‚ŒăŸă—ăŸă€‚ - `DynamicVolumeProvisioning`(*éžæŽšć„š*): Podăžăźæ°žç¶šăƒœăƒȘăƒ„ăƒŒăƒ ăź[拕的プロビゾョニング](/docs/concepts/storage/dynamic-provisioning/)ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ +- `EnableAggregatedDiscoveryTimeout` (*éžæŽšć„š*): 集箄されたディă‚čă‚«ăƒăƒȘăƒŒă‚łăƒŒăƒ«ă§5ç§’ăźă‚żă‚€ăƒ ă‚ąă‚Šăƒˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `EnableEquivalenceClassCache`: Podをă‚čă‚±ă‚žăƒ„ăƒŒăƒ«ă™ă‚‹ăšăă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒăŒăƒŽăƒŒăƒ‰ăźćŒç­‰ă‚’ă‚­ăƒŁăƒƒă‚·ăƒ„ă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ +- `EphemeralContainers`: çšŒćƒă™ă‚‹Podに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}ă‚’èżœćŠ ă™ă‚‹æ©Ÿèƒœă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ +- `EvenPodsSpread`: Podă‚’ăƒˆăƒăƒ­ă‚žăƒŒăƒ‰ăƒĄă‚€ăƒłć…šäœ“ă§ć‡ç­‰ă«ă‚čă‚±ă‚žăƒ„ăƒŒăƒ«ă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)ă‚’ă”èŠ§ăă ă•ă„ă€‚ - `ExpandInUsePersistentVolumes`: äœżç”šäž­ăźPVCぼボăƒȘăƒ„ăƒŒăƒ æ‹ĄćŒ”ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚[äœżç”šäž­ăźPersistentVolumeClaimたゔむă‚șć€‰æ›Ž](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を揂照しどください。 - `ExpandPersistentVolumes`: æ°žç¶šăƒœăƒȘăƒ„ăƒŒăƒ ăźæ‹ĄćŒ”ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚[æ°žç¶šăƒœăƒȘăƒ„ăƒŒăƒ èŠæ±‚ăźæ‹ĄćŒ”](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を揂照しどください。 - `ExperimentalCriticalPodAnnotation`: [ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘăƒłă‚°ăŒäżèšŒă•ă‚Œă‚‹ă‚ˆă†](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)にç‰č漚ぼpodぞた *クăƒȘăƒ†ă‚Łă‚«ăƒ«* ăźæłšé‡ˆă‚’ćŠ ăˆă‚‹èš­ćźšă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `ExperimentalHostUserNamespaceDefaultingGate`: ホă‚čăƒˆă™ă‚‹ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźăƒŠăƒŒă‚¶ăƒŒćć‰ç©șé–“ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ă“ă‚ŒăŻä»–ăźăƒ›ă‚čトぼ損才ç©ș間やホă‚čăƒˆăźăƒžă‚Šăƒłăƒˆă‚’äœżç”šă—ăŠă„ă‚‹ă‚łăƒłăƒ†ăƒŠă€ç‰čæš©ă‚’æŒă€ă‚łăƒłăƒ†ăƒŠă€ăŸăŸăŻćć‰ç©ș間ぼăȘいç‰čćźšăźæ©ŸèƒœïŒˆăŸăšăˆă°`MKNODE`、`SYS_MODULE`ăȘă©ïŒ‰ă‚’äœżç”šă—ăŠă„ă‚‹ă‚łăƒłăƒ†ăƒŠç”šă§ă™ă€‚ă“ă‚ŒăŻDockerăƒ‡ăƒŒăƒąăƒłă§ăƒŠăƒŒă‚¶ăƒŒćć‰ç©șé–“ăźć†ăƒžăƒƒăƒ”ăƒłă‚°ăŒæœ‰ćŠčにăȘăŁăŠă„ă‚‹ć Žćˆă«ăźăżæœ‰ćŠčにすăčきです。 +- `EndpointSlice`: よりă‚čă‚±ăƒŒăƒ©ăƒ–ăƒ«ă§æ‹ĄćŒ”ćŻèƒœăȘăƒăƒƒăƒˆăƒŻăƒŒă‚Żă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆăźă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚čăƒ©ă‚€ă‚čă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ćŻŸćżœă™ă‚‹APIăšă‚łăƒłăƒˆăƒ­ăƒŒăƒ©ăƒŒă‚’æœ‰ćŠčă«ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices/)ă‚’ă”èŠ§ăă ă•ă„ă€‚ - `GCERegionalPersistentDisk`: GCEでăƒȘăƒŒă‚žăƒ§ăƒŠăƒ«PDæ©Ÿèƒœă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `HugePages`: äș‹ć‰ă«ć‰Čă‚Šćœ“ăŠă‚‰ă‚ŒăŸ[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)たć‰Čă‚Šćœ“ăŠăšæ¶ˆèČ»ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `HyperVContainer`: Windowsコンテナぼ[Hyper-Vă«ă‚ˆă‚‹ćˆ†é›ą](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ +- `HPAScaleToZero`: ă‚«ă‚čタムメトăƒȘクă‚čăŸăŸăŻć€–éƒšăƒĄăƒˆăƒȘクă‚čă‚’äœżç”šă™ă‚‹ăšăă«ă€`HorizontalPodAutoscaler`ăƒȘă‚œăƒŒă‚čた`minReplicas`を0ă«èš­ćźšă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `KubeletConfigFile`: èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ă‚’äœżç”šă—ăŠæŒ‡ćźšă•ă‚ŒăŸăƒ•ă‚Ąă‚€ăƒ«ă‹ă‚‰ăźkubeletèš­ćźšăźèȘ­ăżèŸŒăżă‚’有ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[èš­ćźšăƒ•ă‚Ąă‚€ăƒ«ă«ă‚ˆă‚‹kubeletăƒ‘ăƒ©ăƒĄăƒŒă‚żăƒŒăźèš­ćźš](/docs/tasks/administer-cluster/kubelet-config-file/)でçąșèȘă§ăăŸă™ă€‚ - `KubeletPluginsWatcher`: èȘżæŸ»ăƒ™ăƒŒă‚čăźăƒ—ăƒ©ă‚°ă‚€ăƒłç›ŁèŠ–ăƒŠăƒŒăƒ†ă‚ŁăƒȘăƒ†ă‚Łă‚’æœ‰ćŠčにしおkubeletが[CSIボăƒȘăƒ„ăƒŒăƒ ăƒ‰ăƒ©ă‚€ăƒăƒŒ](/docs/concepts/storage/volumes/#csi)ăȘă©ăźăƒ—ăƒ©ă‚°ă‚€ăƒłă‚’æ€œć‡șă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `KubeletPodResources`: kubeletたpodたăƒȘă‚œăƒŒă‚čgrpcă‚šăƒłăƒ‰ăƒă‚€ăƒłăƒˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[ăƒ‡ăƒă‚€ă‚čヱニタăƒȘăƒłă‚°ăźă‚”ăƒăƒŒăƒˆ](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)でçąșèȘă§ăăŸă™ă€‚ +- `LegacyNodeRoleBehavior`: 無ćŠčă«ă™ă‚‹ăšă€ă‚”ăƒŒăƒ“ă‚čăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźćŸ“æ„ăźć‹•äœœăšăƒŽăƒŒăƒ‰ăźäž­æ–­ă«ă‚ˆă‚Šæ©Ÿèƒœć›șæœ‰ăźăƒ©ăƒ™ăƒ«ăŒć„Ș慈され、`node-role.kubernetes.io/master`ăƒ©ăƒ™ăƒ«ăŒç„ĄèŠ–ă•ă‚ŒăŸă™ă€‚ - `LocalStorageCapacityIsolation`: [ăƒ­ăƒŒă‚«ăƒ«ăźäž€æ™‚ă‚čăƒˆăƒŹăƒŒă‚ž](/docs/concepts/configuration/manage-compute-resources-container/)ăźæ¶ˆèČ»ă‚’æœ‰ćŠčにしお、[emptyDirボăƒȘăƒ„ăƒŒăƒ ](/docs/concepts/storage/volumes/#emptydir)た`sizeLimit`ăƒ—ăƒ­ăƒ‘ăƒ†ă‚Łă‚‚æœ‰ćŠčă«ă—ăŸă™ă€‚ - `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ăƒ­ăƒŒă‚«ăƒ«ăźäž€æ™‚ă‚čăƒˆăƒŹăƒŒă‚ž](/docs/concepts/configuration/manage-compute-resources-container/)ă§æœ‰ćŠčにăȘっどいど、[emptyDirボăƒȘăƒ„ăƒŒăƒ ](/docs/concepts/storage/volumes/#emptydir)たbacking filesystemăŒăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆă‚Żă‚©ăƒŒă‚żă‚’ă‚”ăƒăƒŒăƒˆă—æœ‰ćŠčにăȘăŁăŠă„ă‚‹ć Žćˆă€ăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆă‚Żă‚©ăƒŒă‚żă‚’äœżç”šă—ăŠă€ăƒ‘ăƒ•ă‚©ăƒŒăƒžăƒłă‚čずçČŸćșŠă‚’ć‘äžŠă•ă›ă‚‹ăŸă‚ă«ă€ăƒ•ă‚Ąă‚€ăƒ«ă‚·ă‚čăƒ†ăƒ ăžăźă‚ąă‚Żă‚»ă‚čではăȘく[emptyDirボăƒȘăƒ„ăƒŒăƒ ](/docs/concepts/storage/volumes/#emptydir)ă‚čăƒˆăƒŹăƒŒă‚žæ¶ˆèČ»ă‚’ç›ŁèŠ–ă—ăŸă™ă€‚ - `MountContainers`: ホă‚čăƒˆäžŠăźăƒŠăƒŒăƒ†ă‚ŁăƒȘティコンテナをボăƒȘăƒ„ăƒŒăƒ ăƒžă‚Šăƒłă‚żăƒŒăšă—ăŠäœżç”šă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `MountPropagation`: ă‚ă‚‹ă‚łăƒłăƒ†ăƒŠă«ă‚ˆăŁăŠăƒžă‚Šăƒłăƒˆă•ă‚ŒăŸăƒœăƒȘăƒ„ăƒŒăƒ ă‚’ä»–ăźă‚łăƒłăƒ†ăƒŠăŸăŸăŻpodă«ć…±æœ‰ă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[ăƒžă‚ŠăƒłăƒˆăźäŒæ’­](/docs/concepts/storage/volumes/#mount-propagation)でçąșèȘă§ăăŸă™ă€‚ +- `NodeDisruptionExclusion`: ăƒŽăƒŒăƒ‰ăƒ©ăƒ™ăƒ«`node.kubernetes.io/exclude-disruption`ăźäœżç”šă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ă“ă‚Œă«ă‚ˆă‚Šă€ă‚ŸăƒŒăƒłéšœćźłæ™‚ă«ăƒŽăƒŒăƒ‰ăŒé€€éżă™ă‚‹ăźă‚’é˜ČăŽăŸă™ă€‚ - `NodeLease`: æ–°ă—ă„Lease APIă‚’æœ‰ćŠčă«ă—ăŠăƒŽăƒŒăƒ‰ăƒ˜ăƒ«ă‚čă‚·ă‚°ăƒŠăƒ«ăšă—ăŠäœżç”šă§ăă‚‹ăƒŽăƒŒăƒ‰ăźăƒăƒŒăƒˆăƒ“ăƒŒăƒˆă‚’ăƒŹăƒăƒŒăƒˆă—ăŸă™ă€‚ - `NonPreemptingPriority`: PriorityClassずPodたNonPreemptingă‚Șăƒ—ă‚·ăƒ§ăƒłă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `PersistentLocalVolumes`: Podで`local`ボăƒȘăƒ„ăƒŒăƒ ă‚żă‚€ăƒ—ăźäœżç”šă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚`local`ボăƒȘăƒ„ăƒŒăƒ ă‚’èŠæ±‚ă™ă‚‹ć Žćˆă€podă‚ąăƒ•ă‚Łăƒ‹ăƒ†ă‚Łă‚’æŒ‡ćźšă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +- `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)æ©Ÿèƒœă‚’æœ‰ćŠčにしお、Podたă‚ȘăƒŒăƒăƒŒăƒ˜ăƒƒăƒ‰ă‚’è€ƒæ…źă™ă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `PodPriority`: [ć„Ș慈ćșŠ](/docs/concepts/configuration/pod-priority-preemption/)にćŸșいいおPodぼ憍ă‚čă‚±ă‚žăƒ„ăƒŒăƒȘングべプăƒȘă‚šăƒłăƒ—ă‚·ăƒ§ăƒłă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `PodReadinessGates`: Podたreadinessăźè©•äŸĄă‚’æ‹ĄćŒ”ă™ă‚‹ăŸă‚ă«`PodReadinessGate`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ăźèš­ćźšă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)でçąșèȘă§ăăŸă™ă€‚ +- `PodShareProcessNamespace`: Podă§ćźŸèĄŒă•ă‚ŒăŠă„ă‚‹ă‚łăƒłăƒ†ăƒŠé–“ă§ć˜äž€ăźăƒ—ăƒ­ă‚»ă‚č損才ç©șé–“ă‚’ć…±æœ‰ă™ă‚‹ă«ăŻă€Podで`shareProcessNamespace`ăźèš­ćźšă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ è©łçŽ°ă«ă€ă„ăŠăŻă€[Podć†…ăźă‚łăƒłăƒ†ăƒŠé–“ă§ăƒ—ăƒ­ă‚»ă‚č損才ç©șé–“ă‚’ć…±æœ‰ă™ă‚‹](/docs/tasks/configure-pod-container/share-process-namespace/)ă‚’ă”èŠ§ăă ă•ă„ă€‚ - `ProcMountType`: コンテナぼProcMountTypeăźćˆ¶ćŸĄă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `PVCProtection`: æ°žç¶šăƒœăƒȘăƒ„ăƒŒăƒ èŠæ±‚ïŒˆPVCïŒ‰ăŒPodă§ăŸă äœżç”šă•ă‚ŒăŠă„ă‚‹ăšăă«ć‰Šé™€ă•ă‚ŒăȘă„ă‚ˆă†ă«ă—ăŸă™ă€‚è©łçŽ°ăŻ[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)でçąșèȘă§ăăŸă™ă€‚ +- `QOSReserved`: QoSăƒŹăƒ™ăƒ«ă§ăźăƒȘă‚œăƒŒă‚čäșˆçŽ„ă‚’èš±ćŻă—ăŠă€äœŽă„QoSăƒŹăƒ™ăƒ«ăźăƒăƒƒăƒ‰ăŒé«˜ă„QoSăƒŹăƒ™ăƒ«ă§èŠæ±‚ă•ă‚ŒăŸăƒȘă‚œăƒŒă‚čă«ăƒăƒŒă‚čトするぼをé˜ČăŽăŸă™ïŒˆçŸæ™‚ç‚čではュヹăƒȘăźăżïŒ‰ă€‚ - `ResourceLimitsPriorityFunction`: ć…„ćŠ›ă—ăŸPodたCPUćˆ¶é™ăšăƒĄăƒąăƒȘćˆ¶é™ăźć°‘ăȘくべも1぀をæș€ăŸă™ăƒŽăƒŒăƒ‰ă«ćŻŸă—ăŠæœ€äœŽă‚čコケを1にć‰Čă‚Šćœ“ăŠă‚‹ă‚čă‚±ă‚žăƒ„ăƒŒăƒ©ăƒŒć„Șć…ˆæ©Ÿèƒœă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ăăźç›źçš„ăŻćŒă˜ă‚čă‚łă‚ąă‚’æŒă€ăƒŽăƒŒăƒ‰é–“ăźé–ąäż‚ă‚’æ–­ă€ă“ăšă§ă™ă€‚ - `RequestManagement`: ć„ă‚”ăƒŒăƒăƒŒă§ć„Șć…ˆé †äœä»˜ă‘ăšć…Źćčłæ€§ă‚’ć‚™ăˆăŸăƒȘクスă‚čăƒˆăźäžŠèĄŒæ€§ăźçźĄç†æ©Ÿèƒœă‚’æœ‰ćŠčă«ă—ăŸă—ăŸă€‚ - `ResourceQuotaScopeSelectors`: ăƒȘă‚œăƒŒă‚čć‰Čćœ“ăźă‚čă‚łăƒŒăƒ—ă‚»ăƒŹă‚Żă‚żăƒŒă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ @@ -287,6 +350,7 @@ GAにăȘっどからさらăȘă‚‹ć€‰æ›Žă‚’ćŠ ăˆă‚‹ă“ăšăŻçŸćźŸçš„ă§ăŻăȘい - `ServerSideApply`: APIă‚”ăƒŒăƒăƒŒă§[ă‚”ăƒŒăƒăƒŒă‚”ă‚€ăƒ‰Apply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)ぼパă‚čă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `ServiceLoadBalancerFinalizer`: ă‚”ăƒŒăƒ“ă‚čăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒăźăƒ•ă‚Ąă‚€ăƒŠăƒ©ă‚€ă‚¶ăƒŒäżè­·ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `ServiceNodeExclusion`: ă‚Żăƒ©ă‚Šăƒ‰ăƒ—ăƒ­ăƒă‚€ăƒ€ăƒŒă«ă‚ˆăŁăŠäœœæˆă•ă‚ŒăŸăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‹ă‚‰ăźăƒŽăƒŒăƒ‰ăźé™€ć€–ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚"`alpha.service-controller.kubernetes.io/exclude-balancer`"ă‚­ăƒŒă§ăƒ©ăƒ™ăƒ«ä»˜ă‘ă•ă‚ŒăŠă„ă‚‹ć ŽćˆăƒŽăƒŒăƒ‰ăŻé™€ć€–ăźćŻŸè±ĄăšăȘă‚ŠăŸă™ă€‚ +- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)ăƒ—ăƒ­ăƒŒăƒ–ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `StorageObjectInUseProtection`: PersistentVolumeăŸăŸăŻPersistentVolumeClaimă‚Șăƒ–ă‚žă‚§ă‚ŻăƒˆăŒăŸă äœżç”šă•ă‚ŒăŠă„ă‚‹ć Žćˆă€ăă‚Œă‚‰ăźć‰Šé™€ă‚’ć»¶æœŸă—ăŸă™ă€‚ - `StorageVersionHash`: apiserversがディă‚čă‚«ăƒăƒȘăƒŒă§ă‚čăƒˆăƒŹăƒŒă‚žăźăƒăƒŒă‚žăƒ§ăƒłăƒăƒƒă‚·ăƒ„ă‚’ć…Źé–‹ă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ - `StreamingProxyRedirects`: ă‚čトăƒȘăƒŒăƒŸăƒłă‚°ăƒȘクスă‚čトぼバックスンド(kubelet)からぼăƒȘăƒ€ă‚€ăƒŹă‚Żăƒˆă‚’ă‚€ăƒłă‚żăƒŒă‚»ăƒ—ăƒˆïŒˆăŠă‚ˆăłăƒ•ă‚©ăƒ­ăƒŒïŒ‰ă™ă‚‹ă‚ˆă†APIă‚”ăƒŒăƒăƒŒă«æŒ‡ç€șă—ăŸă™ă€‚ă‚čトăƒȘăƒŒăƒŸăƒłă‚°ăƒȘクスă‚čăƒˆăźäŸ‹ă«ăŻ`exec`、`attach`、`port-forward`ăƒȘクスă‚čăƒˆăŒć«ăŸă‚ŒăŸă™ă€‚ @@ -304,5 +368,10 @@ GAにăȘっどからさらăȘă‚‹ć€‰æ›Žă‚’ćŠ ăˆă‚‹ă“ăšăŻçŸćźŸçš„ă§ăŻăȘい - `VolumeSubpathEnvExpansion`: ç’°ćąƒć€‰æ•°ă‚’`subPath`ă«ć±•é–‹ă™ă‚‹ăŸă‚ăź`subPathExpr`ăƒ•ă‚ŁăƒŒăƒ«ăƒ‰ă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `WatchBookmark`: ăƒ–ăƒƒă‚ŻăƒžăƒŒă‚Żă‚€ăƒ™ăƒłăƒˆăźç›ŁèŠ–ă‚”ăƒăƒŒăƒˆă‚’æœ‰ćŠčă«ă—ăŸă™ă€‚ - `WindowsGMSA`: GMSAèł‡æ Œä»•æ§˜ă‚’podă‹ă‚‰ă‚łăƒłăƒ†ăƒŠăƒ©ăƒłă‚żă‚€ăƒ ă«æžĄă›ă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ +- `WinDSR`: kube-proxyがWindows甹ぼDSRăƒ­ăƒŒăƒ‰ăƒăƒ©ăƒłă‚”ăƒŒă‚’äœœæˆă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ +- `WinOverlay`: kube-proxyをWindowsたă‚ȘăƒŒăƒăƒŒăƒŹă‚€ăƒąăƒŒăƒ‰ă§ćźŸèĄŒă§ăă‚‹ă‚ˆă†ă«ă—ăŸă™ă€‚ {{% /capture %}} +{{% capture whatsnext %}} +* Kubernetesた[éžæŽšć„šăƒăƒȘă‚·ăƒŒ](/docs/reference/using-api/deprecation-policy/)ă§ăŻă€æ©Ÿèƒœăšă‚łăƒłăƒăƒŒăƒăƒłăƒˆă‚’ć‰Šé™€ă™ă‚‹ăŸă‚ăźăƒ—ăƒ­ă‚žă‚§ă‚Żăƒˆăźă‚ąăƒ—ăƒ­ăƒŒăƒă‚’èȘŹæ˜Žă—ăŠă„ăŸă™ă€‚ +{{% /capture %}} diff --git a/content/ja/docs/reference/glossary/cluster.md b/content/ja/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000..e88814a730 --- /dev/null +++ b/content/ja/docs/reference/glossary/cluster.md @@ -0,0 +1,18 @@ +--- +title: ă‚Żăƒ©ă‚čă‚żăƒŒ +id: cluster +date: 2019-06-15 +full_link: +short_description: > + + Kubernetesが缡理するコンテナ挖されたケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă™ă‚‹ă€ăƒŽăƒŒăƒ‰ăšć‘Œă°ă‚Œă‚‹ăƒžă‚·ăƒłăźé›†ćˆă§ă™ă€‚ă‚Żăƒ©ă‚čă‚żăƒŒă«ăŻă€ć°‘ăȘくべも1ă€ăźăƒŻăƒŒă‚«ăƒŒăƒŽăƒŒăƒ‰ăšć°‘ăȘくべも1ă€ăźăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăŒă‚ă‚ŠăŸă™ă€‚ + +aka: +tags: +- fundamental +- operation +--- +Kubernetesが缡理するコンテナ挖されたケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’ćźŸèĄŒă™ă‚‹ă€ăƒŽăƒŒăƒ‰ăšć‘Œă°ă‚Œă‚‹ăƒžă‚·ăƒłăźé›†ćˆă§ă™ă€‚ă‚Żăƒ©ă‚čă‚żăƒŒă«ăŻă€ć°‘ăȘくべも1ă€ăźăƒŻăƒŒă‚«ăƒŒăƒŽăƒŒăƒ‰ăšć°‘ăȘくべも1ă€ăźăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăŒă‚ă‚ŠăŸă™ă€‚ + + +ăƒŻăƒŒă‚«ăƒŒăƒŽăƒŒăƒ‰ăŻă€ă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłăźă‚łăƒłăƒăƒŒăƒăƒłăƒˆă§ă‚ă‚‹Podをホă‚čăƒˆă—ăŸă™ă€‚ăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ăŻă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźăƒŻăƒŒă‚«ăƒŒăƒŽăƒŒăƒ‰ăšPodă‚’çźĄç†ă—ăŸă™ă€‚è€‡æ•°ăźăƒžă‚čă‚żăƒŒăƒŽăƒŒăƒ‰ă‚’äœżç”šă—ăŠă€ă‚Żăƒ©ă‚čă‚żăƒŒă«ăƒ•ă‚§ă‚€ăƒ«ă‚ȘăƒŒăƒăƒŒăšé«˜ćŻç”šæ€§ă‚’æäŸ›ă—ăŸă™ă€‚ \ No newline at end of file diff --git a/content/ja/docs/reference/glossary/ingress.md b/content/ja/docs/reference/glossary/ingress.md new file mode 100755 index 0000000000..56b13b2940 --- /dev/null +++ b/content/ja/docs/reference/glossary/ingress.md @@ -0,0 +1,19 @@ +--- +title: Ingress +id: ingress +date: 2018-04-12 +full_link: /docs/ja/concepts/services-networking/ingress/ +short_description: > + ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźServiceă«ćŻŸă™ă‚‹ć€–éƒšă‹ă‚‰ăźă‚ąă‚Żă‚»ă‚č(䞻にHTTP)を缡理するAPIă‚Șブゾェクトです。 + +aka: +tags: +- networking +- architecture +- extension +--- + ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźServiceă«ćŻŸă™ă‚‹ć€–éƒšă‹ă‚‰ăźă‚ąă‚Żă‚»ă‚č(䞻にHTTP)を缡理するAPIă‚Șブゾェクトです。 + + + +IngressはèČ è·ćˆ†æ•Łă€SSLç”‚ç«Żă€ćć‰ăƒ™ăƒŒă‚čăźä»źæƒłăƒ›ă‚čăƒ†ă‚Łăƒłă‚°ăźæ©Ÿèƒœă‚’æäŸ›ă—ăŸă™ă€‚ diff --git a/content/ja/docs/reference/kubectl/_index.md b/content/ja/docs/reference/kubectl/_index.md new file mode 100755 index 0000000000..7b6c2d720b --- /dev/null +++ b/content/ja/docs/reference/kubectl/_index.md @@ -0,0 +1,5 @@ +--- +title: "kubectl CLI" +weight: 60 +--- + diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md new file mode 100644 index 0000000000..044e16bffa --- /dev/null +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -0,0 +1,384 @@ +--- +title: kubectlăƒăƒŒăƒˆă‚·ăƒŒăƒˆ +content_template: templates/concept +card: + name: reference + weight: 30 +--- + +{{% capture overview %}} + +[Kubectl抂芁](/docs/reference/kubectl/overview/)ず[JsonPathă‚Źă‚€ăƒ‰](/docs/reference/kubectl/jsonpath)ă‚‚ćˆă‚ă›ăŠă”èŠ§ăă ă•ă„ă€‚ + +ă“ăźăƒšăƒŒă‚žăŻ`kubectl`ă‚łăƒžăƒłăƒ‰ăźæŠ‚èŠă§ă™ă€‚ + +{{% /capture %}} + +{{% capture body %}} + +# kubectl - ăƒăƒŒăƒˆă‚·ăƒŒăƒˆ + +## Kubectlă‚łăƒžăƒłăƒ‰ăźèŁœćźŒ + +### BASH + +```bash +source <(kubectl completion bash) # çŸćœšăźbashă‚·ă‚§ăƒ«ă«ă‚łăƒžăƒłăƒ‰èŁœćźŒă‚’èš­ćźšă™ă‚‹ă«ăŻă€æœ€ćˆă«bash-completionăƒ‘ăƒƒă‚±ăƒŒă‚žă‚’ă‚€ăƒłă‚čăƒˆăƒŒăƒ«ă™ă‚‹ćż…èŠăŒă‚ă‚ŠăŸă™ă€‚ +echo "source <(kubectl completion bash)" >> ~/.bashrc # bashă‚·ă‚§ăƒ«ă§ăźă‚łăƒžăƒłăƒ‰èŁœćźŒă‚’æ°žç¶šćŒ–ă™ă‚‹ăŸă‚ă«.bashrcă«èżœèš˜ă—ăŸă™ă€‚ +``` + +ăŸăŸă€ă‚šă‚€ăƒȘケă‚čă‚’äœżç”šă—ăŠă„ă‚‹ć Žćˆă«ă‚‚`kubectl`ă‚łăƒžăƒłăƒ‰ă‚’èŁœćźŒă§ăăŸă™ă€‚ + +```bash +alias k=kubectl +complete -F __start_kubectl k +``` + +### ZSH + +```bash +source <(kubectl completion zsh) # çŸćœšăźzshă‚·ă‚§ăƒ«ă§ă‚łăƒžăƒłăƒ‰èŁœćźŒă‚’èš­ćźšă—ăŸă™ +echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # zshă‚·ă‚§ăƒ«ă§ăźă‚łăƒžăƒłăƒ‰èŁœćźŒă‚’æ°žç¶šćŒ–ă™ă‚‹ăŸă‚ă«.zshrcă«èżœèš˜ă—ăŸă™ă€‚ +``` + +## Kubectlコンテキă‚čăƒˆăźèš­ćźš + +`kubectl`ăŒă©ăźKubernetesă‚Żăƒ©ă‚čă‚żăƒŒăšé€šäżĄă™ă‚‹ă‹ă‚’èš­ćźšă—ăŸă™ă€‚ +èš­ćźšăƒ•ă‚Ąă‚€ăƒ«è©łçŽ°ă«ă€ă„ăŠăŻ[kubeconfigă‚’äœżç”šă—ăŸè€‡æ•°ă‚Żăƒ©ă‚čă‚żăƒŒăšăźèȘèšŒ](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)ă‚’ă”èŠ§ăă ă•ă„ă€‚ + +```bash +kubectl config view # ăƒžăƒŒă‚žă•ă‚ŒăŸkubeconfigăźèš­ćźšă‚’èĄšç€șă—ăŸă™ă€‚ + +# è€‡æ•°ăźkubeconfigăƒ•ă‚Ąă‚€ăƒ«ă‚’ćŒæ™‚ă«èȘ­ăżèŸŒă‚€ć ŽćˆăŻă“ăźă‚ˆă†ă«èš˜èż°ă—ăŸă™ă€‚ +KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 + +kubectl config view + +# e2eăƒŠăƒŒă‚¶ăźăƒ‘ă‚čăƒŻăƒŒăƒ‰ă‚’ć–ćŸ—ă—ăŸă™ă€‚ +kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' + +kubectl config view -o jsonpath='{.users[].name}' # æœ€ćˆăźăƒŠăƒŒă‚¶ăƒŒćă‚’èĄšç€șă—ăŸă™ +kubectl config view -o jsonpath='{.users[*].name}' # ăƒŠăƒŒă‚¶ăƒŒćăźăƒȘă‚čăƒˆă‚’èĄšç€șă—ăŸă™ +kubectl config get-contexts # コンテキă‚čトたăƒȘă‚čăƒˆă‚’èĄšç€șă—ăŸă™ +kubectl config current-context # çŸćœšăźă‚łăƒłăƒ†ă‚­ă‚čăƒˆă‚’èĄšç€șă—ăŸă™ +kubectl config use-context my-cluster-name # ăƒ‡ăƒ•ă‚©ăƒ«ăƒˆăźă‚łăƒłăƒ†ă‚­ă‚čトをmy-cluster-nameă«èš­ćźšă—ăŸă™ + +# basicèȘèšŒă‚’ă‚”ăƒăƒŒăƒˆă™ă‚‹æ–°ăŸăȘă‚Żăƒ©ă‚čă‚żăƒŒă‚’kubeconfigă«èżœćŠ ă—ăŸă™ +kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword + +# çŸćœšăźă‚łăƒłăƒ†ă‚­ă‚čトでkubectlăźă‚”ăƒ–ă‚łăƒžăƒłăƒ‰ăźăƒăƒŒăƒ ă‚čăƒšăƒŒă‚čă‚’æ°žç¶šçš„ă«ć€‰æ›Žă—ăŸă™ +kubectl config set-context --current --namespace=ggckad-s2 + +# ç‰čćźšăźăƒŠăƒŒă‚¶ăƒŒćăšćć‰ç©șé–“ă‚’äœżç”šă—ăŠă‚łăƒłăƒ†ă‚­ă‚čăƒˆă‚’èš­ćźšă—ăŸă™ +kubectl config set-context gce --user=cluster-admin --namespace=foo \ + && kubectl config use-context gce + +kubectl config unset users.foo # ăƒŠăƒŒă‚¶ăƒŒfooă‚’ć‰Šé™€ă—ăŸă™ +``` + +## Apply + +`apply`はKubernetesăƒȘă‚œăƒŒă‚čă‚’ćźšçŸ©ă™ă‚‹ăƒ•ă‚Ąă‚€ăƒ«ă‚’é€šă˜ăŠă‚ąăƒ—ăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’çźĄç†ă—ăŸă™ă€‚`kubectl apply`ă‚’ćźŸèĄŒă—ăŠă€ă‚Żăƒ©ă‚čă‚żăƒŒć†…ăźăƒȘă‚œăƒŒă‚čă‚’äœœæˆăŠă‚ˆăłæ›Žæ–°ă—ăŸă™ă€‚ă“ă‚ŒăŻă€æœŹç•Ș環汃でKubernetesケプăƒȘă‚±ăƒŒă‚·ăƒ§ăƒłă‚’çźĄç†ă™ă‚‹æŽšć„šæ–čæł•ă§ă™ă€‚ +è©łă—ăăŻ[Kubectl Book](https://kubectl.docs.kubernetes.io)ă‚’ă”èŠ§ăă ă•ă„ă€‚ + + +## Objectăźäœœæˆ + +Kubernetesぼマニフェă‚čăƒˆăƒ•ă‚Ąă‚€ăƒ«ăŻă€jsonăŸăŸăŻyamlă§ćźšçŸ©ă§ăăŸă™ă€‚ăƒ•ă‚Ąă‚€ăƒ«æ‹ĄćŒ”ć­ăšă—ăŠă€`.yaml`や`.yml`、`.json`ăŒäœżăˆăŸă™ă€‚ + +```bash +kubectl apply -f ./my-manifest.yaml # ăƒȘă‚œăƒŒă‚čă‚’äœœæˆă—ăŸă™ +kubectl apply -f ./my1.yaml -f ./my2.yaml # è€‡æ•°ăźăƒ•ă‚Ąă‚€ăƒ«ă‹ă‚‰ăƒȘă‚œăƒŒă‚čă‚’äœœæˆă—ăŸă™ +kubectl apply -f ./dir # dirディレクトăƒȘ憅ぼすăčどぼマニフェă‚čăƒˆăƒ•ă‚Ąă‚€ăƒ«ă‹ă‚‰ăƒȘă‚œăƒŒă‚čă‚’äœœæˆă—ăŸă™ +kubectl apply -f https://git.io/vPieo # urlă§ć…Źé–‹ă•ă‚ŒăŠă„ă‚‹ăƒ•ă‚Ąă‚€ăƒ«ă‹ă‚‰ăƒȘă‚œăƒŒă‚čă‚’äœœæˆă—ăŸă™ +kubectl create deployment nginx --image=nginx # 捘侀ぼnginx Deploymentă‚’äœœæˆă—ăŸă™ +kubectl explain pods,svc # PodおよびServiceマニフェă‚čăƒˆăźăƒ‰ă‚­ăƒ„ăƒĄăƒłăƒˆă‚’ć–ćŸ—ă—ăŸă™ + +# æš™æș–ć…„ćŠ›ă‹ă‚‰è€‡æ•°ăźYAMLă‚Șăƒ–ă‚žă‚§ă‚Żăƒˆă‚’äœœæˆă—ăŸă™ + +cat < pod.yaml +kubectl attach my-pod -i # ćźŸèĄŒäž­ăźă‚łăƒłăƒ†ăƒŠă«æŽ„ç¶šă—ăŸă™ +kubectl port-forward my-pod 5000:6000 # ăƒ­ăƒŒă‚«ăƒ«ăƒžă‚·ăƒłăźăƒăƒŒăƒˆ5000を、my-podăźăƒăƒŒăƒˆ6000ă«è»ąé€ă—ăŸă™ +kubectl exec my-pod -- ls / # æ—ąć­˜ăźPodă§ă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒ(捘侀コンテナぼ栮搈) +kubectl exec my-pod -c my-container -- ls / # æ—ąć­˜ăźPodă§ă‚łăƒžăƒłăƒ‰ă‚’ćźŸèĄŒ(è€‡æ•°ă‚łăƒłăƒ†ăƒŠăŒă‚ă‚‹ć Žćˆ) +kubectl top pod POD_NAME --containers # ç‰č漚ぼPodべそぼコンテナぼメトăƒȘクă‚čă‚’èĄšç€șă—ăŸă™ +``` + +## ăƒŽăƒŒăƒ‰ăŠă‚ˆăłă‚Żăƒ©ă‚čă‚żăƒŒăšăźćŻŸè©±ć‡Šç† + +```bash +kubectl cordon my-node # my-nodeにă‚čă‚±ăƒŒăƒȘングされăȘă„ă‚ˆă†ă«èš­ćźšă—ăŸă™ +kubectl drain my-node # メンテナンă‚čたæș–悙ずしおmy-nodeă§ć‹•äœœäž­ăźPodをç©șă«ă—ăŸă™ +kubectl uncordon my-node # my-nodeにă‚čă‚±ăƒŒăƒȘăƒłă‚°ă•ă‚Œă‚‹ă‚ˆă†ă«èš­ćźšă—ăŸă™ +kubectl top node my-node # ç‰čćźšăźăƒŽăƒŒăƒ‰ăźăƒĄăƒˆăƒȘクă‚čă‚’èĄšç€șă—ăŸă™ +kubectl cluster-info # Kubernetesă‚Żăƒ©ă‚čă‚żăƒŒăźăƒžă‚čă‚żăƒŒăšă‚”ăƒŒăƒ“ă‚čぼケドレă‚čă‚’èĄšç€șă—ăŸă™ +kubectl cluster-info dump # çŸćœšăźă‚Żăƒ©ă‚čă‚żăƒŒçŠ¶æ…‹ă‚’æš™æș–ć‡șćŠ›ă«ăƒ€ăƒłăƒ—ă—ăŸă™ +kubectl cluster-info dump --output-directory=/path/to/cluster-state # çŸćœšăźă‚Żăƒ©ă‚čă‚żăƒŒçŠ¶æ…‹ă‚’/path/to/cluster-stateă«ăƒ€ăƒłăƒ—ă—ăŸă™ + +# special-useră‚­ăƒŒăšNoScheduleă‚šăƒ•ă‚§ă‚Żăƒˆă‚’æŒă€TaintăŒæ—ąă«ć­˜ćœšă™ă‚‹ć Žćˆă€ăăźć€€ăŻæŒ‡ćźšă•ă‚ŒăŸăšăŠă‚Šă«çœźăæ›ăˆă‚‰ă‚ŒăŸă™ +kubectl taint nodes foo dedicated=special-user:NoSchedule +``` + +### ăƒȘă‚œăƒŒă‚čă‚żă‚€ăƒ— + +ă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ă‚‹ă™ăčおたăƒȘă‚œăƒŒă‚čă‚żă‚€ăƒ—ă‚’ă€ăă‚Œă‚‰ăŒ[API group](/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)ă«é–ąă‚ă‚‰ăšăăźçŸ­çžźćă‚’ăƒȘă‚čăƒˆă—ăŸă™ă€‚ + +```bash +kubectl api-resources +``` + +APIăƒȘă‚œăƒŒă‚čă‚’æŽąçŽąă™ă‚‹ăŸă‚ăźăăźä»–ăźæ“äœœ: + +```bash +kubectl api-resources --namespaced=true # 損才ç©șé–“ä»˜ăăźă™ăčおたăƒȘă‚œăƒŒă‚čă‚’èĄšç€șă—ăŸă™ +kubectl api-resources --namespaced=false # 損才ç©ș間ぼăȘいすăčおたăƒȘă‚œăƒŒă‚čă‚’èĄšç€șă—ăŸă™ +kubectl api-resources -o name # すăčおたăƒȘă‚œăƒŒă‚čを捘箔ăȘć‡ș抛(ăƒȘă‚œăƒŒă‚č損ぼみ)ă§èĄšç€șă—ăŸă™ +kubectl api-resources -o wide # すăčおたăƒȘă‚œăƒŒă‚čă‚’æ‹ĄćŒ”ă•ă‚ŒăŸćœą(ćˆ„ć "wide")ă§èĄšç€șă—ăŸă™ +kubectl api-resources --verbs=list,get # "list"および"get"æ“äœœă‚’ă‚”ăƒăƒŒăƒˆă™ă‚‹ă™ăčおたăƒȘă‚œăƒŒă‚čă‚’èĄšç€șă—ăŸă™ +kubectl api-resources --api-group=extensions # "extensions" APIă‚°ăƒ«ăƒŒăƒ—ăźă™ăčおたăƒȘă‚œăƒŒă‚čă‚’èĄšç€șă—ăŸă™ +``` + +### ć‡șćŠ›ăźăƒ•ă‚©ăƒŒăƒžăƒƒăƒˆ + +ç‰čćźšăźćœąćŒă§ç«Żæœ«ă‚Šă‚Łăƒłăƒ‰ă‚Šă«è©łçŽ°ă‚’ć‡șćŠ›ă™ă‚‹ă«ăŻă€ă‚”ăƒăƒŒăƒˆă•ă‚ŒăŠă„ă‚‹`kubectl`ă‚łăƒžăƒłăƒ‰ă«`-o`ăŸăŸăŻ`--output`ăƒ•ăƒ©ă‚°ă‚’èżœćŠ ă—ăŸă™ă€‚ + +ć‡șćŠ›ăƒ•ă‚©ăƒŒăƒžăƒƒăƒˆ | èȘŹæ˜Ž +---------------- | ----------- +`-o=custom-columns=` | ă‚«ă‚čă‚żăƒ ă‚«ăƒ©ăƒ ă‚’äœżç”šă—ăŠă‚łăƒłăƒžćŒșćˆ‡ă‚Šăźăƒ†ăƒŒăƒ–ăƒ«ă‚’èĄšç€șă—ăŸă™ +`-o=custom-columns-file=` | ``ăƒ•ă‚Ąă‚€ăƒ«ć†…ăźă‚«ă‚čă‚żăƒ ă‚«ăƒ©ăƒ ăƒ†ăƒłăƒ—ăƒŹăƒŒăƒˆă‚’äœżç”šă—ăŠăƒ†ăƒŒăƒ–ăƒ«ă‚’èĄšç€șă—ăŸă™ +`-o=json` | JSONćœąćŒăźAPIă‚Șブゾェクトをć‡șćŠ›ă—ăŸă™ +`-o=jsonpath=