From f5ec0e5db4e8606e8627e5cabca3c79ea33ce5f7 Mon Sep 17 00:00:00 2001 From: Rajakavitha1 Date: Fri, 12 Jun 2020 12:48:12 +0530 Subject: [PATCH 01/99] Removing Rajakavitha1 from the approvers list It has been a pleasure working with the SIG-Docs team. --- OWNERS_ALIASES | 4 ---- 1 file changed, 4 deletions(-) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 34c36cee81..03f8f79b8a 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -46,7 +46,6 @@ aliases: - kbhawkey - makoscafee - onlydole - - Rajakavitha1 - savitharaghunathan - sftim - steveperry-53 @@ -63,7 +62,6 @@ aliases: - kbhawkey - makoscafee - onlydole - - rajakavitha1 - rajeshdeshpande02 - sftim - steveperry-53 @@ -111,12 +109,10 @@ aliases: - avidLearnerInProgress - daminisatya - mittalyashu - - Rajakavitha1 sig-docs-hi-reviews: # PR reviews for Hindi content - avidLearnerInProgress - daminisatya - mittalyashu - - Rajakavitha1 sig-docs-id-owners: # Admins for Indonesian content - girikuncoro - irvifa From 05843a7f9e60ee9edbfcf6417ee3aa4daf5b07f4 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 19 Jun 2020 22:19:21 +0800 Subject: [PATCH 02/99] [zh] Sync control-plane-node-communication The original master-node-communication page was renamed with some new text added about Konnectivity. This PR resync the Chinese localization. --- .../control-plane-node-communication.md | 181 ++++++++++++++++++ .../architecture/master-node-communication.md | 69 ------- 2 files changed, 181 insertions(+), 69 deletions(-) create mode 100644 content/zh/docs/concepts/architecture/control-plane-node-communication.md delete mode 100644 content/zh/docs/concepts/architecture/master-node-communication.md diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000..eafa80f804 --- /dev/null +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,181 @@ +--- +title: 控制面到节点通信 +content_type: concept +weight: 20 +--- + + + + + + + +本文对控制面节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。 +目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上 +（或者在一个云服务商完全公开的 IP 上）运行。 + + + + +## 节点到控制面 + +Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 +所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 +apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求， +并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/docs/reference/access-authn-autha/authentication/#anonymous-requests) +或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 + + + +应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。 +例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。 +请查看 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +以了解如何自动提供 kubelet 客户端证书。 + + + +想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。 +当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 +`kubernetes` 服务（位于所有名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 +请求到 apiserver 的 HTTPS 末端。 + +控制面组件也通过安全端口与集群的 apiserver 通信。 + + + +这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。 + + + +## 控制面到节点 + +从控制面（apiserver）到节点有两种主要的通信路径。 +第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。 +第二种是从 apiserver 通过它的代理功能连接到任何节点、Pod 或者服务。 + + + +### apiserver 到 kubelet + +从 apiserver 到 kubelet 的连接用于： + +* 获取 Pod 日志 +* 挂接（通过 kubectl）到运行中的 Pod +* 提供 kubelet 的端口转发功能。 + +这些连接终止于 kubelet 的 HTTPS 末端。 +默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， +在非受信网络或公开网络上运行也是 **不安全的**。 + + + +为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 apiserver +提供一个根证书包，用于 kubelet 的服务证书。 + +如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和 +kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 + +最后，应该启用 [Kubelet 用户认证和/或鉴权](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 + + + +### apiserver 到节点、Pod 和服务 + +从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 +这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。 +不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 +因此，虽然连接是加密的，仍无法提供任何完整性保证。 +这些连接 **目前还不能安全地** 在非受信网络或公共网络上运行。 + + + +### SSH 隧道 {#ssh-tunnels} + +Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver +建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务） +并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 +这一隧道保证通信不会被暴露到集群节点所运行的网络之外。 + +SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。 +Konnectivity 服务是对此通信通道的替代品。 + + + +### Konnectivity 服务 + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 +Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在 +控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 +启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。 + +请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/) +在你的集群中配置 Konnectivity 服务。 diff --git a/content/zh/docs/concepts/architecture/master-node-communication.md b/content/zh/docs/concepts/architecture/master-node-communication.md deleted file mode 100644 index d0357fb3cb..0000000000 --- a/content/zh/docs/concepts/architecture/master-node-communication.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -approvers: -- dchen1107 -- liggitt - -title: Master 节点通信 ---- - -{{< toc >}} - - -## 概览 - - -本文对 Master 节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。目的是为了让用户能够自定义他们的安装，对网络配置进行加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公共的 IP 上）运行。 - - -## Cluster -> Master - - -所有从集群到 master 的通信路径都终止于 apiserver（其它 master 组件没有被设计为可暴露远程服务）。在一个典型的部署中，apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用一种或多种形式的客户端[身份认证](/docs/admin/authentication/)机制。一种或多种客户端[身份认证](/docs/admin/authentication/)机制应该被启用，特别是在允许使用 [匿名请求](/docs/admin/authentication/#anonymous-requests) 或 [service account tokens](/docs/admin/authentication/#service-account-tokens) 的时候。 - - -应该使用集群的公共根证书开通节点，如此它们就能够基于有效的客户端凭据安全的连接 apiserver。例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。请查看 [kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 获取如何自动提供 kubelet 客户端证书。 - - -想要连接到 apiserver 的 Pods 可以使用一个 service account 安全的进行连接。这种情况下，当 Pods 被实例化时 Kubernetes 将自动的把公共根证书和一个有效的不记名令牌注入到 pod 里。`kubernetes` service （所有 namespaces 中）都配置了一个虚拟 IP 地址，用于转发（通过 kube-proxy）请求到 apiserver 的 HTTPS endpoint。 - - -Master 组件通过非安全（没有加密或认证）端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露，这样，所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。一段时间以后，master 组件将变为使用带身份认证和权限验证的安全端口（查看[#13598](https://github.com/kubernetes/kubernetes/issues/13598)）。 - - -这样的结果使得从集群（在节点上运行的 nodes 和 pods）到 master 的缺省连接操作模式默认被保护，能够在不可信或公网中运行。 - - -## Master -> Cluster - - -从 master（apiserver）到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。 - - -## apiserver -> kubelet - - -从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。 - - -默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。 - - -为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。 - - -如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 - - -最后，应该启用 [Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 - - -## apiserver -> nodes, pods, and services - - -从 apiserver 到 node、pod 或者 service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给 API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。 - - -## SSH 隧道 - - -[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。 From bf53749cf640ca22f32fa43f1c5e438df75d6312 Mon Sep 17 00:00:00 2001 From: Zhang Yong Date: Mon, 29 Jun 2020 11:17:33 +0800 Subject: [PATCH 03/99] Remove invalid /static/images/metadocs/ --- .../metadocs/jekyll-tags-glossary-injector.gif | Bin 41295 -> 0 bytes .../metadocs/jekyll-tags-glossary-tooltip.png | Bin 37485 -> 0 bytes 2 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 static/images/metadocs/jekyll-tags-glossary-injector.gif delete mode 100644 static/images/metadocs/jekyll-tags-glossary-tooltip.png diff --git a/static/images/metadocs/jekyll-tags-glossary-injector.gif b/static/images/metadocs/jekyll-tags-glossary-injector.gif deleted file mode 100644 index 8392c567ef3ac92bd68e1ed75f104247b04b0ded..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 41295 zcmb@tcUTk8*EhWBp$DW37>a=O-b?7AS1Afe?CYbYU9K|nyT(4?tI?;uJSM5=%S zh7JOXieLkt_$|NR{oL2{$NR@S*R`{sJ#*&F=bW9{%*<}|^mP>!owp#rfFs~fqM@OI z!w_H?6BQ%lnKNhD*w~m^Sy41d0RSWegCN9Nq$L@6d3i-dLwQP)!5 z!be+M+sMes($exWIoViQ7@PW98;7`98r%3?@(4BcjBs^z_4W1j^KcId4vCJAjtGso z>Ko+i;Fjpak`}_A6~dMr$wLgZNs90wh6M)`rLM=`NKF#XPd=ZYBSy?qC@hf7&6i3@ zlYLZh;Ze3gUWLl73e}c}q7N$++a61|H7eCq%M`?(8)}susFRu*QW@)2JUx~;JytpW zE%yBjQ(>b__Ol&kj$wyguY)jc{xBRa!x3>V%Rym_NHGo`oj zPG@1${N1X_`l`{+w#oLI!NIQ4&po3r8~VowCa1?nKMxId_RQBlnD2hE+&;MY^}zD< z_~PlY?csMT01?Z|PY{zOs%oXF>1OI0q+YbUt#6v;;E@w?Ez!ffz$+p@DE#KNh=+ke z#qrUp-U)ZY67!;^XYNj>G6~0@%H<5y%mpoD;fuyT82BjCtHSR>tBp@yl+yv z85$by?VBDMeLFZZ_iA!+dV2cZyLXdQ@7|3Mtj`XuEzF#rjGdkg?yb&!-F)|QZu8y3 z+RXggyOr&w4`0^S)>hYcc6N5Rw>H1-t{!~cK0Vp^aj?6)_jzsa+s@aYJ712->DSM1 z2Zukt{rr7;divw&;IE$k|H!z1K#^`_Irk}*iH?<}mWG**l$Znr^tVV~OUpt}Q%_Pt zQtA`{=p>wRI6p870Q>_&g2)AETf0kW#4-Q|XaN>-4H0M8V4Q}TnbDty{yqP}|4oN) zfIqf@DbYW+{wx3ggy`MegIxgtWJcC@aSL|!C*wu{fU>&cg2-bAHcFQBhK1n%;C(V? z3?dT*066py_WT>O{=qJPW0AjftSq$1Iv4;zQad{bc>)0KAO7fTuAXE&w0}5C1h{#h z29PiAk}uR;y`0Grqg^0l5r6+cGNwb4v7pQUFy#3^u(Pwve~daid;SOi?F_jlxn*td zV4RgL(C`nYCgaWk7ZX!5W+3AsZ?Z@K z;J03(*o$OL);|U9x&~{JqX{qrU&Y+A1vh@L`HvA0GoJ+=v)1R zU4jBF{%HVwEx^y@PlW&2N%C^n{}MhWIP`1Yx#%6A3IBtURr<_AgK7RT`loUt z&hM}8PObpC@9wAfM^273q&E1P<-e6DLxQaS$jMQJtoS$^{OP`b8au>=nEeS5nH&@h z7y(*1ZrW4kT8@qeU$*A*rI+WfJ4?XMcXzy=xnL)oEfP-UnQImeI>DX0Qe5kQ~* z-6)#wU!rgwxHcRM*M(pBR|2?_Y5S3nAi(?oAu}YGxs%-sBIg1BI`Ln7unpJ*Yy~z0 zBf;hYYhdj!EC0B9#XBzOe^EyR#sGlXQ5 z{u_$_+YI`Dlz0PfWG%!0tqDnjG(ZL+&mqH*PDl%YhCG9`LPjB7fABw~b^i*F=YLwW z_=}q_*$MA|btE21Y)kz9NB>_}oynztnEkm0!6EM9A>`f%Xa(XTg1kMwLeLuIN3uIw zKfqN?1T7^YDGvaD9`Jv3$m4(i^0OP<6@Q&Ow)`1;hA2=f&xIHplDD$C>4|iDgYIOsz7z1 zHqdj>FlYia4_XFogT8=He}W-kYA_?16U+}52P=Rzz=mKeumji=d=(rCP5|Eo=YvbY zkHO90=im|W444Go0e^!45Gn{Wgc~9XQGjScOd*#b9*`i&bw~;%7g7SLfwYtF^b~{y z*@gUo!l7rNXs9T;dt#v%p{~%Y(Cg4NXaTem+6?W3PC=KU`_K~@4U7XO3{!&X!)#%m zurOF6EEiS|Yl8KYht4|e5Dtek!v)~-1j@eDDESVw$EQX$VFrI5PFOUM9Z95NSKjqFBFA~%u0C{PsVPbrir zOex$bA}BH_$|%|?UQ?`7{Gz0%6rfb4w4(H(jHS${tfB0uT%i0)MMcF!rATE?-K8?PbewcoX0l~n}pu^zCkibyN(95uT26Be?jMf>~Gx2B2&h(#IXM{5f zFzPeY*t4b7&*=F4`At%Yro9m+1mZq6RYexJRcefKQmS>>~? zXH(ABpMA>#<`Ckr;E3WVvI0$BE;-!`aKZ%f-xv;qu|i;p*nvK6mDv+BxrY zIp?08`+#ObYoPtm`RG3MJ~sz9mOGTYn0t)-7monXMV>gGr#y?il)MVO9=ticFL?L) z&hZ)ZMe{x4dwZVZyux{}^Lgh7&mZv%@Z0bc`CIt61Xu<11tJ9=2`mWG2&xNS6)X{) zz5u_VaKZP&y$j<)U?Eu{FQG!A*TP_7Ibm<%d%_bUFcC$O0Fe@rSy5_HjZ@KUqK`zE z#hAs6#NxzS#6F7iiC+@GB|a#AA|Wf`Cs8KxPLe^=Kr&9UUGj^Rkd&)bq13cAjkK=x z4e3_t&oaU??lSjf=48*v8p{%8U&tQI$;$=F)yQqj^T|8O-<6+LU{o+uNK+V6geht& z-camR{GlYL6rxnG^hsG%*;lz*c}qn=#a*RLWmT0&)mgPzm86DNb5bi(BdK$%JFAzd zuV8pFZkTe+rp5&gAC1QvA2lU3gEX5okF=DuVzhd+A=-M{DcWN?3_2He3Uroqd2~H> zAL;Jv$?8Sv^9@0~bBXge7k!tzF8i)pu6eFIZWy;5w{3S- z_bm5K4^@vWk1bDC&uq_aFLke6uU&5~?*i}7K3JazK1aT$z7@Wwel~tj{gM7o{%rva z0loo!fn0&%ffG1kTq2HiRq5*OtNTHQLFK`qV29w=5JvKJXEapsG?Wm!d`<0I;kEB! z)?p3d^x*;FqY*+8$q}28x{(i~pi!<-FQU1lW22X2G-8UcgRZ+=e{qBNM#7DCydJ(X zmNM2i_EnrjTvpscyiI(20%rm~VU?gqc$7$+7?e0mR3<)1f+l$S@_&x*`i%{I<%&Ozs-l+^$y>i%sameyb5LtH4C5K<+z)C_voJ6y~+ES`!x?ZAEZ9` zS>#M7ZLPJgC`Nq3VXPQ!)LCq1( z`z>BAq*lAui8h0_7wyXJO&ww#6`kCjgwG6 zy|%s6edc{*{f7NR1G)pfgBpX+hE#_-hn0rgUMjq78Ic=l9+e$!dL{d+X-sac`L+D( z)^Wx0_6e1V?n(8@=Tq8K1JnA`BQqv56K^iQnVYqrCC$0bZO!}5e|~%I?XP$E1=vE$ zB5E;riDRkc{e|~WNphsFW$oqB70Z=(tFEg%Yr$*3*Aq5qHgY%5oo-fbNo{p*>u!&K zxcpe_t!rMeLnq?_Lc2x#evMhi*IJ%mJa<7e;uWK zXZv3HL*d8ZPn(~czrubae&-)wIBq{NJXtvPKRv}c2RZ*WCxDQ1um^bq-^~2&w%hUJI@DM64qt@Ex-lQ|aj-#!0tAm-mhWCx`+^cgLkYah4 zb|-lARh}x5mgeo(&8c$pY_%?S+08d)ms9T_x6AoY)%sUh$0*AOysruTDkjPygPU(B zcH};3I|^7Cw_7z?w3q*~^~lw-wxb|>ak$J0J`iM!Gvd}dK^>G}`zK~e(9T97^F3q`nN z#BQe*^;zFC=N0zzx%u!E{`*NKDdIIlE@>jo3Z%YQm{NJ(&6nGrWm%f- zd=HYD*#(Qk-eA3RqCBdrDl_?$9AcO=Db^GtCWvW$#tF| z8&C4Z*mrKqls`}8=5C)(XTPZ}yw^Bw?Yq}B=kaK-G2L%Rw0ZH`jz90pb>EL|Tjh^F zwy&4J6YKb7@hhNnr@%0|YB^KP;ML`;49;%0(y{qWBcj-X-Qry^o)+?!ESqcV9$^`oL!M1o(5 zKJW{Esort->yXGh4(V}90a2+5@%Np?@3Ra8!m<{IQ8B;I(c=uv{UYN)H&m@caEoi-%0qeCko5< z?`f{h`w-JxSA6B~f1iw86$x7nI1{5Vt!3D)uytMdRm=Eofu*C(aNqli8z!svKNl;X zoyZK-r;7dDYOZh$+YEY7+d=BwT$0`7h#Iw!_h!6uMCv#_{(Ufg>UjKZ&hz!PgSTOU z$5S0qpHz=tq&`sn;aB)n_2=ZHE2=*~W;_f3{`r~ujpLPu4E4jGp8`*hPFCL^zhvnF z1w6%1?VJNsAk;RwYh(5<7lC*MpF`woFAqmie2tV-y?Jpz9!}VEcvQ_LF9NOPE@|tDU<}opdR!m{C|^;6iR4!G6v8aEw(~(C2fSw-JebHUF7n z)~%c2Di1jI@(0!U$5Tgq@1HZo4$9R8W(rL6ek0lH=)&o5nFp6~Zwu=0Do!TmQ9JQV zR$;LpaoNJqH3N*CzUj5voN}Y{XUwY%%&MhsJxyCblPWlJ$@=x}&u1PQ;2FZO98c`VN;3^!FSt@hT*^F2OYVBVo$A> zRgPQDJXacu!;LDnsE`x78=vpJJbNBRA!MAa_JxprP)Vcp(;%yQvTR{(3)`P(cB?w% z25U^RyxdQV0=CBT!A@tLs$|o=@`(xscOJ8N_QCvt>`JV$4~ST8l`q*;WtLv8*l~Np zVbZEv?)JL$PS})AcSwaxw5#z0p%*pRYI6gj!tAmatf5&=k3XhbW6Z(zn_WyUQ&$&mzxR*_R$O_24u&KFKK6v7qMq zyrxH9oQ2wh*O?pB6`oko{j%(7KTJ-DIT6)Zr+h7bT_!cVzhIkHSQURvOU(4Yye`K4 zeEH|iSPfqmi1UW6FPnJMaMN8YSK)UbE*-VctI8Lg>t;(I=Z} zzXCu>dW>^NgHQNpD0lqO~LH~&K^OrCw_|k)q{M> zF4w`?f7Ro1mFsnj7D5xvntz1=QcR)xRdI6xt5c(GPxlaST#-%jkRkMUd8pcHF1=qXT_wWiy+iyATD+dB!38Lgv&OT zXAHd+eMbY9ii4u7ac*$8=biCR8k{wLNs~p#w z?AlB!nP9qbC+N9aEi`ujgT<9tI-^YRowIc?#)VkQr-vA-OQcwRs?URu9ZKxl=EiZf z-v&+k#d4|My82mPEV5y8Vg>f$+IKZT7GBVE3}}M--B=3fempOE0>U^xPwxrz07{+E z3v0_u(Un(Q;M{S-eKyoUW*l!b4m_$9M@I<&Tz&%|g@HIao^d=6@-s-BZ)Is&wilke z@I+k1i9Wp&+;Rc~;ly)(K&(yt=^o+0YFovW;Cz{LfjL5a$ptN^h1d`h9+W>sJd51 zIjN3me(-I_;NV2(y(5Fg7xDUcA2k#76=Jf9snlh9S_sV|*w-)IP!TT;V(>9i`}?U+ z+F<1QuP_cgGF#8ijUS07!QC@KF*qEvL{z#NGNK2WfQ}-Xxj@UWG7ULit_7u=!KrH9 z+~fknosji<-WQ8ta=~y29+6-M3hY6C?e{I4y-Kx@U(@tR#DJ4$MPr>nq5H^PCc9_= zjKl$9IQIkqJOH;?YVljKv2c?oyn@;$v=d4U`+X_k29rmbb z9oixU;C!`_Q$*scewbh_GHeiGI1bMMz)mE{euE@3xq`Mh7&Iv9+N{qq5;XOBv zGQ+jCJct;u6Unh}Fhevr0ZQ^=mH@7sA(=?mZ=#X5D(i-Z7Z^6=6>UoKLZ}!nBGR-aVZS+&+ZLQLo`6RNB6@Bb zlVDY$vTn?H)vqw&9y#an$BDhIowgZRUcMrgp!2?nZgoKJRf148k$i1b=0m05{321Yd~84rLx zS?{gY!vGA-4g+(*!Fh^&zrTQeeUrcjz^&1#X+?0RT9EC2>7^c|OA#o^Nm?<_%d`UQ zga$)vaq^T8)!TC=h%l=nKp@jgnh5rwEK90|ab$XR!huK$4-+P^ZKilE8n}RmNmIgO z$Dy~{!cXXDouhR@H;)Pe5N@kl4t!;mblTRmO4pfx8fX5zBogc&0u#*+f%{)Ve7K$G zf`M6~;UVRS0E|;48g4j%a0PiSo zy)R>`LorT#gO9Ekz>-MSIic`!rPwHmQd_f%GlFpIo<|Qa9_U?0Gv`t+NBmD!Hc{?dTb>DkCcG_*siK<4tK%j->%jLowc0}t@_Albx|;#Ei(Ou ztUa@g_+YQXgHolAi%J)H#lJJywZqg@OU3W6)@4oCaZyQdp4A*us1^Jb^P^E)pzx$# z&rXLSMW3~rLAqaZ&8^~ne1o{vrHoK4p-8p*qP)7Hc9KlhYp=!v*=v#=CN~XC;mX+C zWm=*gchZ#_z~@cTGL3qSjrSgEX`F3b>uX~CX>6$6Y$MpDJaDaXTleCls)gJBx7l;t zcl5@-H?DZLFt1zBB8=NYv=CGlZEOsVTlLDR+Ls6|h#4z^)K=(P{o~u$%)M-5sTh_r z;T+nnKV(|2!P@d4X`ae7-5W{6o^9uKYZ9EuDKKnzDQo8+X`kzFJ;`oA%BgzWS8IOT z1bApsFMR3InsMz;JK=2mr)k=zjt)A5#vWlkkIhicrkLShogA`l=O%LI%G63vsJbGi zZJwoei7D$2oNZ$$tL;c=l5OnrOSRo7Y?aOKegkVCKC6+{*DbHBqkO)5ZlFu)u**6> z=1ZZbaca!f>1Wz}U0lxTFUp?X7V3GbV~b3CHrU*c%e+)hdNNtIFMy^m5uIIGz!K%U&VCxY7EcxT{`2yOeJH@>tOI$wxBee z$5+*XT3&y(PVG#;7qwzTaQ~IwfjVA$6=}EU4Fg51{R=DoBj1$6rTdu-~#Sck0sP?&Qm>8+@KEg&WG}OBeM@4Jg6&ZY>qJ&9H_h=X} zN>lE;IFLrISiL*&nn^q-t^dN*K#sIZWLdw5k=(dWe|E4!m67r_4&7;&K8IF#hrM}3 zexrDEeS#&y!peS5(5_3Qb|h3=>rs8Q%AlF0?v3nGsbKxP`c0v0+AsXNI`68gzk4;( ziHX>HHPt!t&QFz#aqKg7!^&taW20Q@yWZ*Fy+`(SXU>YP{eIP-Gu&Acjg4g;sn?61V`5dT6L1oVUj;)QZW5wl4oy1m~-;{ z;-u)4$#Y$kGWRCsp1>tJr}&>t$uCZ+9Zzz;nvy!6;uW3N-kVZPpU{t)){U7qc`|)r zaoYHJTETe6I%dY!c+yaHhW&WTFlI_NecDd-jlJp{wCJ>R%p|cEKKg}Wcbo>tIUA%p z8{#l~EoL_S-fU#oZ1m#n_2XGQ=UklXT!O<~V$599y}9T;nv})4^jC8?Ip?!f=W`t9 za~EebW9AFG=I<`fCmE;b(7!EFeOu=6wtVqSkw1NvD*Yo-)+fgFPmL$4kD2Q@8Jp6X zTVA2s_UJo|*}7iQKZ|+$LUkd6exWaB0qVRk)U`0WxG;9SFwVI+d7`>F?XdVJW^wM` z;@hspg~i3C<3$qZ(u(TRn#0mY%+l7qr4L<8yNgR7kC*m2-+xhkf8g-`Fy{UDd+&dC zz5l)V{^a;Qz(oS9k)Vzw_;nKUK8doMM7>0!Jt3jEmKoHR86B6IuP?LSUuN%K=2%+h zI$1_@t?;O=@HwvVUtbZtzd}>905_*oSY8q0T9qmUazK3!9*w!_$65!2+)D zq@3)IJ2Jfk5V|JmQ8m>1TrjK|w4rD_e{5}sM5*rty^Ep!x=*R(1gXN%9v0C)ae`{2 zDRtFQq#nvu3DmU!y7vGAi}|=pT6sQBC80*$F#hpL5v4kc%FHBv7eKsnqWel(dDcUL zI;GM_!L*C0B*ti1Z%|fAKm$%F+fjRbS5Ced)zN$j*va6cIs|Cdim3PZY1Hx5hp5d0 zHN;&r+C36w{yy#YIAtM@wv`J}gs0s>Axdh#eBFmOkyiHhp)YF>?(Wkr(?WGmDC>aL zGgs(H7*Jj&%{Fe8=F`q0n(hgP@^GI@W}Nz{h(;B+xkrN3;c2%e5Mrc_J`y$mv!m$1 zcZU*tGh(P0_`|0FCD@$qEdV_zqPc^idj~*w1L*elA#|ryF9PTWQP8hyKV~qfUKF&T zhDKwbwigX85JQ&2ytv@$cc8PhvumhWL4rvq&R92fbQd{%RjAr zD1yFPIvRTLTN(6SUX0rAL>-|~OVxs>dJI56*V3e`Q!6-8wMrbb)KVYrQ`VwU&zvA_ zxRVw$Fr7MTXCLDHk<#lEWwko$nFQsdK&l$k&+k#NHPS9bk`ACp3{_d;v@bRcis~yy zec7!Vk@?8-B=T^#DOK~;itbHL)$33;i#2T4dE@)qcP!Qoaz!1w6WA;_j0$A^m-_Bl zZkpUzjX8m`%Xs$tTe4a=&Q`xsQ7p!P{?KGtpz42T3uZY<<@412<1R(~#m_dV%AUrO z2HU#(!ghN_Dh-hbd(u_uT*KwG8RpS$HyeFoe|wpw|E+e} zPFBJh5v#8rWA{{VoWMCR9e7PXG=89aPf5^R;ihQZ&cx^vhdUS1y;?r)jA}-=i`{P~ zpZ!69-Duh7BT8mHn`eZ1O#_ka_kyvU0V334uKj^J5|@9=tu0EJVc&88sJV0;dAPUu zjCk(KN%YTe>MZX0`$Sw+pI7vI54LKY?;v6ey#sq=gXm< zB5%v#^VjKl?x(KJ^*!b5`|QP~P+;y`8nH14y&vf)@~M!@?U6wK>8{40@UQDoDJ(aU zuO7>rp&isftusux&ErBpaX-RwVmbG6O68v1VB=?QM*9+^`v{c_+u(iYNCj9PpT*}} zrB~qCPb{2XZ6^fcB_Rt$3SU7d{&`@QU_)s{N#-kFToDP%q7Ww-eE&*N(faLk_C0>I zc3FKgmd5hyjh3eBFxiLKYHsPWd-bu6-S=&LSzZ!at0BbMP!>B_64AJQ{#jt|vOD{d z-)h;L^w#Z%d438hxICZk=L7enYQ3j)0{9PxIGwJ=4#=i9&iAujty$hY)-e6#r7&hLz8L&U`pRO-b>WnI zA@f&SZhsq}dOH-d5cug{>4c)D(9Cm%a{=Ki4yIgXZ~eu+L$(Q@RK8DZyg!cIpc!*G zTD}#=d2r)No>c#bUV#TSUo$q3kKVpN_4@gygKqoB{JV;0-`C%%w?-f7Mc&^7hu=Fn zHVG3_ocnr0si6L~i7yt-c4e1R0dw#$Fg$+Z+_y=D%IVCfFt*WiCz|qVClO{*yfWn7 zA*?#{wQ{a6cxP&NWN*~yc%oz(Le&kM!T!c9QT4!?IzGJj><1iCMaG5pQ*mzul0F%m zuzV(uwVzvPB1yZ?h5k{i_PHZED60Re;@j0slS|WLyV$@OWYo1N?io~*@_LZ@TEOkac`n`OuOD`sKtrm*eEt7Tq zJf!Ys<+usveIK^2{+heqsdwR9>&vSpS;V!nO_4=?o#^_k!e2(~@~PjkeAmm9-|nvR zF}07&)kqev-*r~%{ce_M&6pq0C9MY>)%5fINjshVGYiJy9Ra?Qn~r z0I6zThia`rg=wj31|mkb+U!-nW$IYNJ&Twsn&C@&K|Hc44*tTX@hLiwg-iwQp9o4$ z6`YtSzm$C}0uvTGQkqK23aO2c-f^D4WN}sL_JboUKR3_zH;w!<<%FDFuJ^4IqRq0k zM1Oa>W1%^t$hx|>Y0DZQJF6j!?CKVg4Y{@?!~2uD+22C;EPq@u5o?ya)imSfCH-R_ zU7cG~L{s4@ZHQgIf0$;#5n%Js&^X>ByEG?#GpOmT-D<#W$NQ!&Pejzz`WWOX3HCHt z`mMu3^K92Mrl)f9RF}R`=l6_5Jd@%~8cv-GAcFYga!Cos!g&*hm<_Fc+vA@XyX zYYu{VPL<_h_-y^>CpcaAmn3PEmL7(3T#{$LQ`5;y0_#U{cO4@v>gim+_`uVY#nhD( zLJ;eK{J_M4I6H{f@kr;#j3DZy}xUs?yVg zo(D|zH0Pr|&lcFcw&0gBNL|=e5-*sLNDD5~8P!6oNA~3|1(xV6pp3%aPCbB!RthY* z7?1Q$NIyQvHofO={n+c6LFoh5GirfNLie zb}x4V!fFEZKRBJ4co&#^kT+<*7yik1;W$8|omUu#XR$91;dhIpSn`|^i+&my()zqb zsW0kW{+#m7@DAyZzR9Ugt8%}^gINp)v|pDd^3(BT>vL#RpB5Gu`wKJAvVYy1w0{{L zAo#>#=}O^^=%;7TwbtAavn%@bo50d?ME#^Q+l$E7BXjM1*^cBli9yR3pGVX5x4j+4 ztM3e>P99#mGPY9l@m-JVr+u6BJ*S!vEjsX<2iBqvS0ALZ_vj3MQN{4ChV-#W$}WVl zv|XnQ;e&HZ7!#FSO|-%o)joS|u2Y3ojdhA;am73%4hwYKI#q}6C=B|soqhI3f%(LG z!Y|ajE-LkBzb{isJM_0_>HXktDcL%GS=VK%PqeSJek_IS1%}0n(}}Kze(yg$`1Hzn zv**J&*92NqCTa0?%UcM$b}M{xFw)?n_9{@%n|ydbtBrjH#zTU8>Q~HlAi~f+ zHgDTlgAf7ir8hnZa=gTpuJ9MW>>1V)@(SWBEO^-Sq5Fwzm7))EK3=A_T4+5;l#=nn zyKKajaS$&$?sTgAO=)vFdpF*-^{i#Ld2cHxm7;XL8bBfp_6V9t%RZlj0ZAwD3lnOi z6pbtNr7SNApM8@edlE03!2ktt+e%3a7J*QJX%r}Va(DZ-6088g8uKvS?0i%a;^G{v z3B~t(NS>|W)?OyJidD-d1n&q)tVL+KloCg_i$^h(K_Bk1GEft}c-}fcGE5LyX+YWo zc#qH87q&HsBch!S*u-Ob6E8J_bqW!Bn z)b-l)cQn7&-(E5-)kx^A+EI0#R!*%f)*aQ^eAE|-PrQtQ0sF8Ed}y>)lSg(fk8*d} zt6ZpC24 zRZ?Pj2_|?P#L)u}QRqx*C352-GI!e}`{0~d*b?hdoQzNumdJr6q>LBGj>4lKBPcuJ z5OiE0Y9R8vUVqV}U_li>EMirPm^7^xj750kH0^SV2c!{Ee8j-;V*a=KA>qX@gkOez zhX-#xdDz)HvU96Mn>t!$s4q#-kVo$BC=Ak?nAl3Z7eZvwObf)S1SlX@ei`_o)!#;` zh7I)uqlgV_55riA!6ele4TkM&hWtT@U@t?xHTtWqhK-H-9Wt_;%EYct9RtIm;8vcf zd?U*!9m+N$nM{)r;;Jnotw8^)W?FFV;OpqVlNa^vckbSL?q{&x0BzXMqUS9z3fXfXpAU=HDa7{*n5G=95SF3Zm72_wqZeMp^q?G@zo+All zpHK8nQXA1GShXS?0X)wfh{FsPA|dXF0dow2F7^z5l!@aQk3G0cbR3W6=mC)x9E-R^ z=3rFKNdh<%RsO$8C{t+R357y{3D?5Uyoai7`_ zWP%4n;GT;W)<#_1isev<^G!Mt2yud0DZn6GvA*buy2nIyef7{srK>8ivw#J{D>uXz z#?ceY>y_)UWzM4jc;spa*tq zcfxB62DB0)C5Rke6ZQabF_Y-qL*PWeaRjhL41!YuTx-DuMaQ`pXQXZrNJRi1YaxxoZ0O)M1U+39K(Ca8#fmf0D4irFon1*Q8S1ab5aC$iQTRn%+W^V+PDXyt`>OoDS_z+t3!)ZC(v6Pzs{7NvmDeVFJT z9&1{Q@W6vio#3|NAW$(Jn@_l!4`V~2u2v=(I3>D;$F3_N^!F3|S{*>2VE`ULB;m9A z;T#fisqO?`9R7w3-m*1OsuS)9;P;{Ui`Y1he3ZSPjkg!x3iB3dec=V*EhP{kmjRjnro9zig9%RWFGaa97$i9>wp zd_n1P<~at;Q-oD4K!lNEO)JHt%m`qGDJ07D0RbM;n%KO~eWx$>=3_)828Kw2ha@E; zu&~iK^35kSW)dyE@TwnO`xY;F{z%})P$4!5NwS0#)R;pif)D4Wy-P^M2<*fIS9?r@ zonV$|1S)+BTarVFv@I*H_zE0#q7#4mhpJ0b4c-M{woNU;&zL;S` zMd4wFMTQ==iNX1a#-Rw~q-g`&#H%NnvA(tr4wZv?{wmmUXg8l@gi|8xI5MmjYFtDN zc1pydh~#}g@=MJ0T4G=>an>PGs2fTcNOVNQ9i8p`hCq%ziO3|lV-F};P|F)f^z{NR zCarq4!jY};D`+P_&A0Acw~06Tn>B@Zo4)ue z9MO@>RM-z`ZM!Zs9g7TqkCZ^z+pb#_G=xgT@n8_L>{w2GJo0=ApH3>pMOc^u3>X3- zhd?RrFIUq5YZA>#2s#eF1w!`3o_AYafY}sM0wCNA2v&eu_P~8U!YF#+qY<{Mp~$d& zg26b{xYlzdfsj6sU|74vipq?z_3Rh6(yvWmEh0pe6M`$D4n>K{j)|<532aFTtVvMD zVz?n5YFKnJ3VD_OHou(q%D>a28pqe(|Yh<#;)u7uV( zkw|F=uSzY;${;`2S;B#0YW+#@t#>!;Tom@!^sLbBLT6 zLdu-8^;WFnx#5d~ZWJVfm#yuEC&-XW&?OXg2sVz31hc#a_amj>>ZJ0%`Zga!9oPVmOUKH(VCg@iSVAp)f!8yRydpNZJrZTqC;)0WLdz@ z#$nnkJA_$a2y0xiyP_p)T%UCsMF=spXvAM0xPBw>RFz=y;0r%zTp;;H-yGH+mk4Gx zi~`_Y*9Bkrc5=lQ6Y{W6E8)nzEQ-NRJItsdo)D1;qcu&Wt4NG{L-5H=^e%$8Ya99G z!?3nDDOb=J=~ZC`}Q<8qtY_MvuNqmjMUW4o2|4c4$Qu*%KnS<^=4C z4w>D3t%)=k*urC{u9_n+oZVLw>ga>{D%Q|PqS|2+1SG)n;C45!mrn$G{bFvQ67D$3>bsx zT>iGgLzg?96%D)FDH^XFr5jCLr?Xg^vsF59+oG;=bewWm7iyh@2cPuS_@Ts4a2 z1g8wpHd%jVS6z*Du8-#=eh zyg%2i9{#OIpyRVqQ$C?3_Z{}cZLSgwep-qDFL`Xl@S2-90gy) zrK=vTf$_9j0B%GJ$#e@sJAt&N6F(8zz>N?TNKQQvdRAvzi}&;Kv_b&&EeKErb+@2b zVns2@C`fE$pysXdWAp&(RfG8shJlva`KCC?DL9pOjuoV5NWW&*m+JGd7a{~K zW#`bN@_9*BY;9VvRS%}M%%Mg1$sfAXYZq7wcbtNMrMrEGbIsqWo%r4ZS~N?B7+&Se`>=h=ewFMaIciRaJNW|)zZ)Gndm z%Sv+1P{_jYe4=t#lukWq&c=RWQEljR8a|)N$7`yp%PnXEblIO__abkZQUW>$IE>6( z0<(im8#dEK^`l#3y~>8$LuFN`^i`SAP*{m#E5on%&#BA=ny z=@w=x(-jS25O2XijAf2+y{R&-q!%=?2iR;wu~^@b44IbinkK3hV_K#%Eemlgo?ZJd zQa3e+Ipwik-)UM^G&F*##AY#R#^PN-?}*s=;|7#?HBLYt`zSb%OR1;!CQZW^zfLXj zw*9!9Z*!`_C&rJy<;SPKAHkI#hJ|XuX_O|0>|e`wR8CU8oWtFqIa+#V5+frd0Ben6 zc$gh8^mxqSwQSoi4~>lA>xMG5#8Aq56sMxfYs4BVVY1Wp)NETWY{PRlANp>k)fw?7 z3QqUaz!-CUMtRuYgeMg)<Dhqd3IeM_f9}8C%KdES2y;vP{MOM&9 z{@$~?^-f1-msurvT9k7(Q&&HL0TWU-c)l~Alb!qU&gWukf5)?h=lUT&tW$qk7Uqgys=xy*^Ewj*qd}v_WM?Kv>?O z^_6jMsfd9j#lc8YvQ(%=9fE~dPASX@!UV^dM@*hMi_~As!(OG6|5ch>+9zPWtda6K zC1lj)WhwT8MWLFn-N?0|wfvEA4Y{SZm$QtNw+SCS^{5X}+%w<_$4TrZB&I z+&Q6wzrzLoVacV(s`+5W)8OJy3!#F}wOJ=2%cO~r^6kd$NX#9%125wW$^Pvdcp*7c zhNcsLTWM1UZn^fTOsQn?^OTQQu8q9ZuUBbp^s#W!Dzd)7q>}N=gqK${L#M9q(PYkt zNWLn1%_`9{cKtO=n`9c6&pe^_2SRdoxjB|PvSlBlcfwXutiH^h;i*z~yO{l=|F*GL z;th&jo8%WWVjpK}SLp>}Yvt#WssZ_=*xUT8i04nM1nNl|FnW95c}*oI-Z-WYXo8aE zgD+Oic}@P8nsVpveq?Tmokm8b2rVF99n}1Y5REE%$@N_Arqs|AQ>)v)3qMu(-7aTe z4te1Fpd)hg;nJOtVIL!Dua28*mO{kcDX6UKm=9}A7*inL!j?b8^14AUF9pW@vOJcO z@;&J}E}i@Bd!>x_yI-$rZJb}V!%2Blq1)yCD34*MC#pvehqZ+wZ&5DS4nOJDjyNAJ zr?PCgk*5mdl1#CDyuw80FZL0eSUloVlN>(qTeL3ShQsw_;m}WE>2>n_*VUs&*&!I$ z7cG^u4|q#OhhUmg*YAp8i(NkTi;dN#oTjde2HzQx9q`TD{(9+xbpEKDbntvPhezX2 z&ryk{FR`yv`edit#+FR4LisD z2DRxeOmWMl?9=q8J(0&!nbYB%=It(QzoHLDy?j5NbUuJQX$wH@voN2cuI(Y8{|-9f zt9(ltj!=0kSR9f%D@I}Pd)<2(5qS6gyPQ8ID($~Ux4n~`H9t4q7(BWA$zC*16E0^o z!2T(8x!$?w^=HSXZ&ru!_l5V>e?7KTT|(;hqh=-EXNS7AAGW+M932@N_#n0SnMKS+ zL)VPm-Wj@xwDcbqe80YxJ zEU<*m{E2U3`i$7nBMJX8`9n5s^p76c94R@i)J$2St`m#GmnRofAr>>Eu zY;JFHbKsHGO#Sac)W`b+G4`=G)z7H7ZDZz_V{*T~5^vs&^UOXTGH(f$_;+gBdH!0* z75{JC>Ke&TpFMn^E`D*<-Lq7F=R6O4I11{I?Z|f9SJukw8f%XI`RL`~Vd%e~ug_hN z+N`$tY&W()@3uYD{0i45%XKo6&2wP<>gJF7W*dvq)<2i|s^`Z4w$rWp%x-tWdK+hd zYfXP=AGf?|M;pqao@;x2lLKQQ5clQcu&66A@szgoqT4P%C$(g`J;>c7f=GMI{YSvW zS04)e5+&}`6{?;0=J@G$QDNxYrwsh=2yO8GBiN7j#pf4hb|1MdfJ)v}Q>cbBR71o! zbvRq7b)vz@ftIzTPYH)?ukuYx_FIAr;&3)u2zzh|d$5O9dWn3{$^qy+SEL}%vl7ly zLEica9(p!zrezE10aa0hi+=?99tv{Kl;|5EIK~7y%{;z6UlC9c5{N932q+Pl7ZkEB z<#iPjoDpQ>Smog_<;_~Tbgfi4RZu8vh5xaqgsrCtR7gNlC~3RmyMYxqwdT&MA)ARCAA*zf5{IcYl;C2bmP^prv@a65& z%QK}(n6(5GVY!(SWm#dRi4`6*PvH$usbDX*rZTk-VN_okYD`#trc8ZFSYxA1V^3J~ zXPG8d7!55)Gl^(%lxy*eXkRMVmKD)Kmg{JUVD!o{W+J+_<+`pSdcNg)!6N#R<@&co z3{uMtvP29YmKzp}7(FXDsueMADmU&BG3hHe851#`DK}jbG219N+Y>SWS#C}h!9pvr zOrjPX6&C!WmX|6lWks!!6;>Le)_N7zW}-H>6*jJ-w!Rg%!J>AN6?V5o?Ncl4vqT*p zRyY)kIzFp#tQB=?s&MKMb?&Qh9usw$sc>1MR$QGaQILg8W_c)Vi@HLexiekz;CSZ2 zf64RGGqZ=5A{;q<9Hl&}z7mFzzyeEeOJAY-2_MNzev!}oWRD=t_`C zPYk%##a8f4g81zEEt+d%bwWUr0-mchZle@&^B=y&epZ z77IgGhG~d}>s5xERfcZ>H-y9@eJdl4e8PFrv}dQGT=?iLzv!&Wn8$uG#bU7!Dr0N? z;<7er#RpMAVmD_hZ_ ze$R3}qg6a>V=J_4iv{d*k19@p2B4R!vN$Bt&HS_JpFfb5$e9qn&n=N_RGBO}7=e7A z=PL2AV@?kh5SA)-8%avm@Bqr44aPAk7HCSS*o0lT_ z=$v>#)|XpMq&g(&)&@XjCA^Rwp=ATm@v34Enj~J@zHA&4&rc0d8cBi!Xz4jxl~W)r zRpKlspnfVD#t&5NZMDjZi4(ie189Z1?l*c;w=?`-xW4Szle!uD{5i5)6-&A_m84n# z0O>SRXXi5DP8oYZg4``9O?w#w3WI9N8R$smJ_o=cIZSs=sJ6;nxBM|)c0s3I<7@%6 zlHa9_)+L-abR{{Y{i< z(Npcwl2MUrC=JYPt)6xb^3-?^6uh{iSghVg1BeHXaR55)@`8VdPOmVG4Hdk_N(StOIq<&UgXEq_KxJyt!R( zW&M<@yT#hNRlm~6=F+Nt)kd*&hbjcp5NMWZ@CpUhz}!xYrNl~8?M_$4ifWR2gZ9Tn zSs-(F?2n}Q@ph=Hj%qp0sAu<80_|lA4eFEzKy8Pv?!MaARx7M-u-w`)llxIzv4W&M zE8?g5q$S5BRXk~IK8g2h?Gg=1rKkD^!g6H5 zwC$^ZR5?4>eRVEr7831Q?G)x{FIRP`rSI?6c1sQH$ph#sbF}j5iAwQ0bm6;l)apdF zI-S4sNl0h3!blSJ#a?KJe+rE}Lo?2ryH+7SiSAfToYXB3)>0`qQ7xxs3#3skPg0xe zMyBsDS|{!Q)uvg%E0Hp;)+JVCbgQ={N*Cy~mExXD4(_(pafE!c9QzU)J5(fF$#{SV zOz^BMT3`x^76mY&0amVruGB9qT%hN&n*cb0b!0nq1K=}9GaZ<`qp2+ky)4LCZyx)t z6^ee`Bo)55d21p7Kz$G80EB7L#B-86-1V12Ld{|?11$LG=c+*1P*A#9^iQ$q$Dys< z=;+X`na2wFrce<(1%M*u9;zU_`Q0!$prXlN^xyZeiO_W4dRfjl)XPuG#q^&m%+??A zzqz9MM*q^Gf{sMCp0J|Z6{O~Rso53fS9|G8p~$p1D(A};qr$REw^b_NsOE&pJvmf3 zta8lVQXRjd{@yD*Hx#t~Mq~eq=C3!J|E{26ikgQb%Cm2@E{3BdE7hJHGF8iKYbs(s zJ=T^}ROSrFxGCzr<5JCq`h+*=d(rAA9qEUK8{Ag($qm;}Q#8tHFm&r)@>VqIKhmqM zHkoZOl@l_Z4ChD`Qu!6`x}=DOHDZ~SEI1o2E-G1yHCoCkSt&PKX)0OkH(Hx3+1NGO zxGCBCHQI(K*+n(l-Bz+sYqZZ+a>#FVc&g-B+35I6$*H-~={<*%bAO}rxRT3kqsy|A z>t>_tzLMjaG<61Q(RrWAa%Z5{e|pw`de(n>)>%;gKRxR|J?noJs{Yfn{?oJm)3g55 zv;Nbw{?oJm)3g55v;Nbw{?oJmH*NU;ww{%Crf7j^80hKg>HbH$qy@vyv$3&pb90}u z?eynaWEfyDDRu=}HenHADJdyMMa46&T}4?%T0xnWTilQZgjJ+>yvnL*BO+#e(bj;& z#*96{fX?5JJ+3r^J6l`ZSQ=r29L=!y*KE8ayuG~x0|Udu!{g%Oq9Y?i0wcq{U96G1 z=@Gn{A)IM(!ig?o8PT{DU*m{7m(x=u^6y+q&sTnsuk<`$^37w(%KPH^&ro;EQ7siR z&nuN1Un(^>sa3yHElj-F-+~-`qwwz^=-)rikuLR_KDB>TssBOP|EWH%ML%!VX=>Ac zm=a!bKd!k~?{%-x0LsP@p5(bOl?xoQ2+A9W9wF(22==GU=b*Nnbw7@w)@M_Y#f zsM@E8XX?7)uU{scUoCeItq*@#pZv7=@%xNiKYJX096SB{>-FdNwXL1#e}8YD{D|B+ zxHi8LLwb(};0dxyDV(AyY6f>rEC@~kIe|9_k+IK$a3yEf89jXKg2V)@xxttKn|TX}2=c!WNVLSE5rNMWj54OQ{G=A52P0%FN76 zOH0qo%R5ur^YinwGYM4%sZ~#M-c>$)Q}*EDqvksgY93WK=T_F2m6f0Q?3K?dDqE{w zyl5}4Y(ej){Vntox|PT-6JC-gZ;gIL$i~UlM4$A(=(qYKakhw$M-hoKQ4S8oZVbl-Co%I zAGdw|^Z&T*TbpNM`_A$Ao$cN4Ul0GBS?zyMfBrc6d&cPg{PpW__cLW_ zxc&cE^tk-P#Q#tAxVQD6hYPM;UmAJ)W^kmwjU)FQ5dJ>;=t!)E7=h^!{|NPK7^2_IZ z_f(0E0`G?b8;|^-J>Pg7*z{%NiPO;Q5yEZn`)Rz<8_ze3<9~kHe2RxkZV{6?u5Fd1 zUwW}snu*-rDkJDgeksqjz4oP|!1u+MXN4Pdu=1yp+%GDNhAvAMS7yxnzsTJ1=q;os z_a4G{W2YYL*EB6%ld5gqzOnPF?a$D4{`Q}(JFj|HTX*W;{&`$o+ov5DSl=mWTvInK z56z_(vRcLJL?>ZO8OhUQOdJ1Apn z)ouN&PI7OLYwzwgtO|`(x2|QK>^C3T?u5Lh-(=W(e_`{bY(K4&v;2FQ)7=~Ic7(3K z>N{~X2_=2Y;5`^-eo`nu#GvW4-wyfpq?UBKS?#cgGh`v;4Jt&scKo|`{80nzCzJZ2 zZl<=QAsywwu<46#E;oh+#o8g&NrSDr&0n6?{G1PL-u?Lr*T4Id&wn`R*JAW$%`fUw z{IA_#%XpaVF(sKZ_;@8{Q+e-rjiBGr#P2|mDX4BRs{OrD7`69%lbCkq!2S&}`-=;COti#j*8%;9>b$ITz4syMqH9dUN>{y9jaYUU>WNQPq; zdJpjGnY{cN13i~izlCAqSJ%wM+x}W$GYC$r-&Rx7q-vRhOy1>jyq7=WanBsn@TpQTFDVG|t`4zP&)hd&|c_QMEoc z(c77~Dhk7V=|gaEozBWpRkKGIRzyKbpEU*IhH4qT{xMA2d zs&FsprBCZT8rJ?+i!pX;Rc7%SOp#dcWXIJl81Sf8^m_tV0-W=5)@zt2D=Sk^OUjjX zY;&~wj-Tc`JN_n;spoFVlcjaL%ct%y{g~Fc#tyoRj&KN1a9Bt;HNITq*GHt%pU*d= z!gOE-xL(vxnWwnJJT_UPuDW{yC_I{$c8Fl)*;s;zJ|wYTYwS@I7X*y`b##CC4W@3N z3%+pxXuUVA&T%|K^k^r-w^>xw>q=-m$T~b@#I&nbig~efiI<5h47!qQ=Ux@)T)iVY zWlZj(&-rRAT=S^bJYv}T204ir03kHJWtr}pa2C&`ni}I*ZE*ltQN-hp3AU6yj*_H= zF0u9#%uTqzzIpt8NV((O_$%HcKerLv529uufT2o9`H*5*9AFt_;Zr>y9s^VBx}4P! z`sG}XKw`hDBJK6`Zmun|jOoUQicn$~B=&-A>o+OpY*DH$^TRq5C6EKkrJt~M1(2>4f@$vEt+t+>q-CQ?6IR>#FGI_BCoY!-QT^+Gy&hftV zJ~@NV(b|LSeicUX-88JkQkyFjp3Kt80Mj@EneSF#di{r(RyRS<5|f_9n+dv8`qPdX z-=cH%Gdb-tQzcNlh6C35gpuKypP>!&L=0>2ci>UsrU~llTJE)frRs8_+(}-55~cWuJb1H z$yZD|!D85FX7|xF=QFjKqoTFha#<3^#b=nzk4aQk6gE*b@;-u_sKZ-KPLNoIh1@wxf_}GRebIr)PcJTb~~qqQMzME3g*P8D0Vj&k_w{4))j1&wG?6rIG;G z=PKhVlwTKuJ^H}auERzs^t+H>rrxM%#1zg;LtdAn_b7%|xT^ADe-1x&IrSZuAbwaFVPk*|3SzwFUwEr|P`O}ox<75_sJsoh6cpeZ)MI8gQSaBLaew!A+tkBT|cvd1h z;oR4iI-LR<*jb22?uZCnZ%Klo@emO(nlZEr4V03>t($^$xAx=d{9~o0y@^agaQuZm z;%{*Q5TF@ML)%482C!3hegZVKL|mE_fTy#qhIxty66i^_@#BKnvxw_#+(OL)5#6(IZ83g14^x2iP z+-zr&@fIzR3k!^gCAKaf)|>~k2Y|g_aZzMiPI>4-7 zEHwQvz(qisP9;Qx1!xa<3MTD|HJWROrDCQcstP@eHR zdzcdukxfC^xFhbP8GiqSH^?*ILo={$z#GU6*+d3BneHCI*okGl$3ovu42eb~3Rvi6 z?dba583`2nF*JgCGc=b4uIJCtPJx$T?X;8-kVwWH7Ptd3%v=<9(Uwk;lO9uUMdgtP z+tq>Y{D86((|P5=aX_rY4447!Xn+TW$wNQ@#2ko=M1yE?V0nnXyT0~HL`I~Qp?J6< zuG=Ao07bY5q4hv2mtY1g5IbUQ#{@`+jFQEE<3Z8#5CNh+oqdkJ#P$$&j;<4DDHaCYe@<05ihU6qoDz)kSq!f<5q%{7Rdz;(;Bjw4yjE zx(l~Cv9NfY{m8)WAS}q21PgHod9uKG@lLD#V914F4S6cKSplL~XXS^71-ajim51yf z$6UfEa1rh8aCd&TKw|~&szgdPu|u06abgb8NG!;U1hd8wAQCz7k2yULpmu0j=mD6; zMoPPv?j9LV#KXd{$@%zXa1(tm#o7iPmWM_ZvCzjIz{vR2LNdK00X8E*mw<&V9Kdgp z81GRKVFDgO>2zIKNIMzMSBc1?Fhp=YYQ~y&2*GC1blNuVHdsWVJKb9{1DPcy4)Dax z>iSb+f?1%E?sr^cAP{$GP?{0{u@^5166Frk!^3W{JNp3h71c;}fn% zA3}KqX#8*xdbCsK4~J_+nBx>!kVo+7D>&r2Bty6aECUH3Uow<~ zWEFq~NnChJnWoiukGkv+!q%D0J`55=16Oq+!f3~p3%8fIuq==gmt1Jq9T{DBuq&Eq zjDrZGVZm4sTSbxakqgIwToktW(piI2tkl(fx(D)%*$4DEB4h|nH%5SfHyDO-bbR@+ z1uWeVk?sM&NF}4`O5_oR2iCC!hKGcQ3j%ZjbMS`%<3r$4500(_fXyDjOVCvo_6RaS zSAt{sCHk(#@ct13Fv~gsg9h{00e%Fq zItIQlx zl&J(W1!(#)rQsA>3nF$k2C}aL5hP~5@wei@LbFuB!PuuB#0RbfSQv%Ym<0XnC{;L} z}a#zDQ%&>(^=>JBW+K8o!z$m0O4z9nTqBoH3Tvd>c?TrG}` z+7Paxl7KLX$Dn<5ol8av%upVDiQ5SBvE=EjuhAdh6V)}P=sAx)zlj<|JqphH{oc=rr{8MgA}aV@FMUTtgjfM*fivwla~BT<|!g0}BboG3K!#9<$JQ5)gwFM5PhK z&F43w>mUOHbhi%jNrW?C9g%=TWIlq-9KbpA5uKE?*Be2SXDp@9*7Q%##nL^((c$Uf zkI@W?1uz`e?Sp%IjSnmcfbfzljO1y2@DMM+%19pU7!J8cMaDYG7k$u$hLfRu1S{bb zjrok4bshteH#+p^IG5&;j@|@UN0>dnd}TFVHU_3ihIpf+1dKr@EHLjEV6l^u;|!xO zL$7=Z&^kL41EV^3q?46#dkBU0N}lvH&ewnMcuC~loS=>$2^$Mqy>EV2_)f< zw?9oAtCQ{lC_O_wXc6+nQ=;YRN4jh*Y={h}cF4m9fq{@O^szXPl7km{0&PPqh@a2i z-g2OesDsP{t>-ovY9AvK(C!Tc$bkGK2QqAs0-JWHi|IzU~Olfzr#rS`q4my#RFNtGV*PG-&WOZb$e_?0!p5r1Trb#=F~wpii5$ z4DK`+1QNsCK^rRGdVSHC0ASgm6Hx~ZA;xZ{b^iAErbW|eV(}{v@MqCNWhEjQ?{tF* zCOrlTQlLZnMaAV0Hs)f!W>P_i4@)B^!8;=$P8LTa0)VLl8E4!oS+}x(R4?abS|8JM z{_}efX)N3i#&$QGj~*<02g)u_yx|Aal?TMgpK(QxR2cPo7Z<1zjEv7jb%w7DM61s}UMFGpf@(_!<*WvQ3CpV!TKNnw(F3IbbTrz_WL44s^ zu>u-P#_LcoqG2Gx#EJw&|!#Z(@brFoVBI2M|PLv;#Brw62K}kYeNiWF+VwYDEp~di3 z$zZET9ShI+wX2WKcV26z=xEVdp_6mXDCJiICS|51m9=Q~W>Sj&f@QjUbYJPp^ss&P z#K^upmR(7{-2MQHVS$EFJ}{e^e8K3C(!dhj87AEs#t#rR?hK6wh$hPJD)r2`W0;g@ zoT%HSxb8I`(2wKxK4~y6QxUI-yGLVtKl%42>-Ls3_P;LeZ7$VTeHt7++xveERU1tHA0Kgr+XCl{i%?9;+_LTJBV3p4-9Lsb?sule0$DCFiT zE$6zT9WJA(9BDPmq3JT+i(FxcnGr$U08L@j_a?UQQcc7-7DPqdk-^g=qxVN9%V)DR zkFfhkV??)R%ZZ$b!$8`@X9dWG<~yGf^krRKPq>Qe&R0v zx>F7bb^8^0`&abSUpVt$x7lpnZf|p&>-e5kjO}>ye20>aOV@<`J8k934vhPyZw8Z= zE!xUi?=SO-etYA3WmRP7_P^iuY(FC}|0KS`6y+!`uRFTv>@?MWJ<|TFn&Z%!RF$jK40d_?@6|tt6%w@5P$zYdp?J2NW`#__~6vm5sr{DI5d+$slWf325 zI1ip{r|B!a>i@AbQtZqRD^fn%%E~i+%zsa{;@U(_Nxf{0!(rfj;UVvC=1G&*BAnsp zj5^nG@KW!ci@dT6(R-`ycm5$e+OCFv>8Oy3+H3oBnEbIUWOm5~74>=H`TmT?g6i-6 z!B@?<$Ehtb`-h{;uz!DVMW<|!!~U6T{(7;K*|Byid_dYg*CX3{ur0;X^=(LstV&;L zj8g}$AXwCo*RNo85ISG6+N_)l=4jZDC(K&3at$Hqa~CqRud=x0vMPV{U%OnVxn3nP zAP{oCen9AsqQc-~g7t$zks`%&MxvGFp@WhYZ0CjrE2k8OB;TBd4qtlOreGrZ?sU{d z@xAjK6XdALl@Vl3JoTKR;(mC}FsdIFX0C9uZe^yjnQ3LJ*$%cg*E!GF@IjN=#+s}v z2+8@N&!@{aW^!5mJ6Wb<`?7WYpDIrV8MDzi0r;uJHJC_?3 zO0%v}5Tw0FnrM@~SGLO!JMVnchaVk_Qjm@Tl@(2n*I)G_or0P_H#vp8=d*Rdh1Aek zTZ}JOKk_N?Xm*KOPEmG^+5A8BxL==}-ERMbsJJJ-p~G@#MIKe&YzrILgsF#r&=+eDpETE3kC?XeYmb<9OH+^h z=vUbu`6;AdJ!&y(vps70HcTUWB~7d&dd)6>Gx~GBA2q!6Nt#CNmr72h;?3v%8gaY# z%rw62HN!OHzuBaU@r9qIQ>vo-K5WE2ns)Hx3tzbKk}qiD!r9o3Ut-tUd5p9mOs?Ou zVw~l~#&uGesPNDZyTP* zf-31OPWCzvHgN+pq|*l;VGDfs0|5o3)_d1nOZLlKP?SB0md{#;|C<4X(f1ofm%M-GF!X|= zs3qw!;=<5p1YL=oetLUU2z!l+2(x5#Ki@5y)I%_7W$&x-AFFKQ>CIc8Ue zqh_X_HQx0z3x1AB-VC1s>k)SQL(;k3?Eop^Ef zeyyZ10Ug%Mh5dR~^bAGSiPf$@?x?r}3=Shg@GA%IEHfASd2*8~7q6!Y)kjmUI)1W8 zUiA@E(9p_uX>n&O=h9_~{Wu zJ|=u~5ZIL+cx>+fvx|K&?4p9ZJA?C9DfeD_KWm8!b96ZkPrHgPV&^_Bb65APe%;zH zq1z_p+Aj7Z|1{O5`x-VwNu1?47^?hJmP%~HP?`6Htsmh(e_i0gp@yncovnj(2JK*bUp@R z=+6HuI#dMHtK3$?z~3emqmOx|j=!1>KF5Mk+=8mwfAbW(MZ-6TNst&}WqP|O5;MRB zWH1yMs(1t2NW38H^06KZJvJ+PA@Q+> zUU(@hXSQp4DO;IJigM%xlTCagTP3ATC0L6TS=}{JG51m>ltTaKCM`Rm5yB9bIbPVH z!=Z8vmi#&7-z#*OwK@RFe6Pj8<#pwaN|o-f?UD>$qBh5CQjKKCOMhSGcQ+2?_sofl zIsTi;{O!KqHDYM888?$Zp;~`}A|`_T@;@!4bT?rU&vlBZBpqIbf}OXY)%U;N@q%gd zUSN$d3c2-5Eo^?e`8`Afm&mz5f$2wgv3KB7l^0f+)1rGsHEv|sEv$0(NB1dp+{lVr zSi1;|8PL@TeUQJfE~XzdWYZD)uzBILTw2VCk4D(z*@X?|{+O|djh&>R6ib`jgKjFi6%`J?e}LB zzdm*Q)pe14RBV2_NgFaxzU}(wgh_o>^l8j{PTXmS-^r(T&8Q{h(x?54&7XGMf~r^B z+onU*c6K^e&R2}^w70Ekc1ykb!_!RD)jk_ny!h_j$`wsWCOX6kJvZ6b>ec>bhkxUp zXxAYU7}5B2z4_axX2#^Sj_c_8^Qg`o*e^l!#7iWo4Y?E0G5O^E$Lk&2@7{mx?&Pd~ zH|EqywnCM5qJ*qF5eW3;{JSFy4e=4Qh{<~q6Y6{3Ou-I@Hr#dPlb32gt=d@1+dq4$ z{k@LjUwHUs+OOilC*oDJxb)sa3BajJ(^)D6Vwsl{Uqllx4;y^$=s=GOh1 zB686f-38%SRwDggCVEB-z43~AR@BTMqp6-Ck%8OZy-W+bo(*~-@qI~%KI^Y~PRUI% zBRwgZx;`fQ!GW0MDg9J$y{su+&2^oOWHn-mo;AiW++;8>vp=_7|6%f=miJ(Obzeb) zq0dzRlO9Z7?qFW|U|6!@{gJ*Rwlg4U&~HjdA=A)pYVc8Ye_`ODk$0OmqMsOU^fYj& zdTOZV)UZ~>D0g9?6g(WTFjVz*DE4%yxM!d~a3~*TT%0^ym1`VtZCuwj)Pym3=WU!H zINW|T+-frXUV89pjBzKgarc5|H_D{9XOQGQQZGGX%4_rnWAqfI7prKLTR7AhKQaOy z$+YepjUV|SGCILKT8HVQK9$z{a5_AoI69j=`Y73Gcxou8e5fbWv}eS0K7OS1#^@q= zjKVfHacWA;99|DIDfS*3;~jg_F#0xdY%6o{Pu$o{wdwfO;3~?jI(O{L`q-9<$wKnT zE7Wjvyz#fMV@F5BtF+ud!pDEbo6L9{A6e^9=bAraGu$jR(pVVJU>kWMjXq|>J}Dmu zLCg-XV6COe;Pzq4l-XoFwzJI~%5GL-Xh!cd(&bG4x-h=HfPFGz0_+;MNRKmoHce<4 zTB#lbbd3+e28SnD1mh44(|-meqcGT4J%eq@`mCa3cY4fD*|1`~<6X`cxtSLEPHlJjTbXO`aG_E}H&cH<(+{tq>XIR~LRU_2G3PSzFPfA>Ojx z*=i$xNZVwj_G|ZO;i$yDiLWDlD2T;Eu7;qGq2ymH<99v^Ar(tBbjllC^x^L|MGip^0hG!jO5MgWhE0iWQ4qXWF90k0ZZv6d>%3^pZ*OtXK5eFT_DFZPO3S7+-IwJ9AWrjiY#bK zPF$R;#aJgLJJ9&pcAjFN1{pEPI8u&24mmrX#ye_H8@ox{wIN0n|Bk8^TD>eZ87;IJ zKeT=FdBi_&RBrdy3p2Hgahxo4dOk{SO&Q;Hsu)blAQh5S&)#>Ho(Olj%D zJqo^P;<}P$rHFgJk9*vyJCfI9dvt6*d}&ph%%`^qLoV#}II!2aG2Zg%;+ucxLiL=N z@i@-(EL)r)3Jxil4%N3e9iM)3Ekd@Bbnx0*tFKQCRJi3wn6+P@-H9+CwQ++7+mvTo zG=o>>ewg{Bw2498cq%3&X4X{xu91AkpT0H>FMx!Q#v=s=uC=6mHL^qIX)X=PMju11 z(o^gysRIj82m3TD_MT`o%oqs?B3dcUScU}7HWa1>6+j{gu;}>DicPNng6wZWK1REL zmU6Nij32o1cfi=%USY96B)-?1*Y^eclGnPdO0jX4%xA5_G@MF`v7UFj$qX857dW$V zX=!8O$ZKwLuoE(k1Mtr7Xn%%Ip5!z+94Lat)Bg}^$~{Uo2Zl(p$46F4v+9)lL?u=kQ_+H z!}r=p{{OBxIsAQ}8X;%j=x?$vb7$(Eg8Fn$VSs%_H>V2=KHWb(XZQGkK-Gc+7IC zwSRQPk7GKOv(C?fI40L&c7bn&ySOQ5&)3{#<>;oj_{pN-@Tb^@P*G+mraGW2iAq^%Ed5GAKA*8_TVB^EJOuA{Da2kVknKw+=&W@G=a?0(W z>)2k?Nh@zdMVUq>o0%NQSuFc|VJ(e!`^mzpfs25qcN^6(>r3*@uSsT4345FDY`f@i zn2b_QN9q^oZg&ieE-blyenaPMi*w0%PR7EJFLdTL%0{2T7D{!Nn~F!X(&kew7}-X{ zZmI1hdLxjfHjK+L_PrfmI>og;qUv9Jn0mNswsIq`1$S7O^M)wgnu@wKdgQx0Z|WGS zL@sEb3TZN9sBsBl0nW_P5P=jYJPaofi7QBpP=N&FVbFrco9K^05Ro5SKdINUd9jsTE%4Cve>z=Gz1+}P8we?TY#X+vDBCo@L*qCcz{gML) zWao=h9p6La!qdK8i;S*IvsaOJP>~LCM+K2UeEvSsEvfoC&v;rOZyrvDh(q|eAh>i` z1p3n2A1F)zo&)}ya6d$js+{704v&VzjQcP>}m}b9W?9L5i8#hr_0Q$joAh z+3{qdopkCPP0;a1ZnT-{MvO|JGaAN;18Mg|0D@w8%Vx}(O4yQMiNkYmtq0-oas?1h zEO?Lpi-kA@5QoHzUFSqs-%^$hC+-y54mtsNUak~qdO|xg1uCCnDUWx;X-AwvoZ?*} zI1rD)Gj1-q=xqE&=I=2qf2_`~*$Yy1i?+B`An<|jA~1j#9%q5`D|rvH#^D>7`y!+N zM?(bczj0yH?ls3&*usMB<2Y3SUI1`NPqPQ`3^e%HZax4xjwc-wK}vwND1@iudF)A_ zlG3Qo^1m(9@zAYJ2Nu9eJm$iy1ekn0Ps>TTKpK<~53d4+t1PgeI$i&CT2zqAjt1Kq zB(t>$U&n&%(xEzMckWfGZ1&08^2xeb(DeeC6BguRmk?mT_xWk6sXb^bB!%4|*%k}J zke&tr% zmkAQlRR9GzScT$ohpVG6RhV5-aZ0WO^{limC|=bLcL0`-jwAHD_m5 zuOm|0vDR<0K4|CX?o=agvn%gpT6VE5O6L3S&M!F%DG^4SI;(hnlE`ZGu_~dqv(te+Q^jm1M)uuaJuY=rI7ZFHOz-k1mN$-{Th+R@Um`Zbf+pd8mq-ZdbYUm1A2K6-)-7xICZE_~35s28_>SzkE*3CZSqj~g8anuG2O zVyzhCRU5Z!`=rBI2`=y4LpXq?9xr~`1QiULaU$jxvUN4dBOA;nLGgOiJ-dNfH|^gnLK6_#J||19rrh0JDTS~$bZK2c;htJ@OIMLpN=r@_eJ%MgOJ;h& zOZ4htc#gKxk^PklH8RU86DmcTCRZt?T*r)loLt5ve1~+NN%C32xnc27(P5p)*%q{! zgi5t=sp?VB#H7Sy*{xB~UO>|D^Ois;1^GQ%nB+6ki%(+6c`j^>-1QGn(k|`$K1%y3 zP=#6LYz(FK>w4>kF$QE6?YK15#CF+EeLF&?smbS^O!H#wiHy^XD+7Pa=he^CZ|BZ6 z$-didb$Zfbsl=YG%nHa)=oVfTxPKKoa*kO-uIh?8HK~3bn!t!8$xkT5{H>tcGxD2c4|l+)VHeswzP6jr>n?uLK6OuvXm+KLsONV==0S` zS^O1xi4_t>yGtYN{I+TtvW{_>k;KwTOX-;;Fx_JZvkjN$$l-{k4vZwNSF41f0`4q5>9Rl-_|6aI=_u3_p@@<*e5IxBw;cB6`9>3BiJ^lI&e ziMrJJE+fyj4|tw4ByO1qmyOlFFgzgaPJ5C{>wSZXYYNR_HU&}T{#iHvJjwh>-qQhh zcxE;yY*6z$*Mjz!V18Jof2Kb zlaNEd7>{DQAxEzHGwJ2dXjh7zh8_WtEUo7E4~bTk`Cs0&*|^Q z6PDC39!exaGz6%;Eh?mjKuU9lJ90xKg zP9cY&iEP_jQ$hB&Nq!|lG&}NXuO(L*gH?L@XJ7iy3yyFRARZS=nn9QW!jufxj1`#x5x37982S z8F+=C`kHp=3;BLU_`;ZRBRoecSdS@?Ov{_@ZmD|K7#)KWhKyVID{rlc5nF_w?rrfQ zM=|0$tWw=ubI^?L62@=3?mStas>G2I%83Cwd=)I)Rs09?+t_5GBY=RJD!I35FoU@u zIpbsB_mW4d&Q%f$D6D%Fi%bgVLe;F_KvT20z3i&x!b|M%tDo6|fA}_Q&9;zvyA-k= zQZ_vgoyH_Lua4{R2Nb1crE3$uywLG|YHx352*PtKf*Z6xe)4c*sdR>;VT^+kdIS(Y z+2s$ho*4kd+R62uYMq*3_;$Wu6zI#dX6o+Bo^jq8-CUK0f7%0w7hdKu!K7}xt~pvtl`leiXD3{QxgaKH5<_;NCox_@p%aO6gr|X)a z_zvn)=-u-ZGlwNMq(geG%=*)HS!gynO0s-Gqw$oSI~p*~d?*#q;EH=hC!Vrrmk|mSi0BA>B!EZC6>!SeCL>Ylq<7fB+qi?AQ9z*o3=I4Msd~ z2YSW5Z}4u%(^}TorP(xDWLUN!CHDsUwigc>twVB@rQM+jSMvxs@o* zcTSn&iY@38hZB(kI;vlvp5Amj8$f`nPLj<`l!&HPAGoNDJ)6kg)lH;5Taw^8WkMWAjX5G#mrcR8izak~I!mUy+3qkK94qG| zhYpOc#Dr(jjS=0dvo6^l313}l6#lBc3CANLDkuv=|MBBe=PKqapUgSRa4s4CoK{(d zB*B}@l`44a(W4-eCtZ=SH9|niGS5TAsV$Hw%Dn)6D1@|yv=w}myrk!OnylhMQKw?E z8`oqdOFc|5Dl~TgO8{&Oll0KQgD3(;D$b&q;m~0K1&_hYH8Nyk)W$UyV^IKwxIITk z_F|o3Br#IN01n<pk_-sE7Yq*kaRO=`tO?qpbm z%y+aSQM!fSAtFPH+YO)uOEw}{5Tgk-Wd+X;#EN z)?{dIMPG(RW)>braOP@y)g-FRwq%iP>cvCOrexLy2<0Yka@A|nWpJuc-aW8fA2TXIE_1QEF9rZsl~UMS3>g zZCaHW9%MNxr)iF-ecmTq;6-5KXSpb*Ns<|2UMGK6;(!)txww#FGG{K*Cr)aofkNVg z3Z8&QC~Hn=w|M7xQm1qpsD@IghxX=e{xGOpzGR1fD2G~(Rt%?!+GbjAVu`M3wpgfo z=I2+aXe0tCjRIwkl0{@jBm#Ei_|OiHSr z(&Sohs;9<~rhclZjwhrN=Wtr;IJNxS zWm>%>wq`3=jH|6aA>(D$u9_=djH?E+tF$_vN&>4}uxq(uYhR9OxYX-d*{fyNtGHaw zXo{;`vSh%5Q0^gV!nW%>Ud39XV`CqyFPN&e~!^=Q9xYq?G=wZLmu77kjzzJqshe^w)q?G}5bcJFMb45Z z*7hvao^8=qZCu2Qq?-P%+Y+GI+HKh8t=noPf{txFPNU7zXKeZf&<$>16s}nrF5#jk zU?8qvDDKZO?q4`=SwU{(+SlS@?hIM3cS&yMaxP(jZbeY;;d*Ya0)=3ZZsiUJ&}r^p zh;HecE?|hR>RvAFnic8>M(wf-?Cx%z$!@!}?(Oyk=nC&A7BBFQZt@;4>n^YFhHmq^ zuI;v^?>_Hf^se)oF7`^V@^UYol@4jvsd$Ag?F&nqB8^19e$FUsGF&)>j9p5n?mlZtV!X>>C z9Qkn{ztJrK@*Dl(APX`fA95i3u_FKRAbUn0N3tYOvJ}IE&)f?pXR;=5GADPkCx3D$ z+raQrGAWm`Dc3MO*hB*u04uk$E59-<$FeNXGA+Au12DuX=dv#E@(j~M%^ZLL1hX&? zGcgyl{xKgjGAHve9{@viA}>EPG)FTCrx5@c04QHGHfOUZGcyiIvp0V;I8QKo001*< zvpJvhCv!9ShBG_2vpf5*FOxGm&oe#W3pc+rKIgMO&u=^#QnNy9vH={x0NhIeG=M*EaspuVKMTMCBtRz*v_zjYN~bgp zjdMj~vH)aq0uVp|%(Nzx^u4^aITwHfAOKDSfK6*MH#@UR4>eI2bwYP?13Ul$BtS+> z00?AsMhn0I3;+$7f&~CTN4s=JWAXq5vrhv6PS1cT$Urq~vOqg@QKz+9OY~7^vHL1Wi8P@}bOm$!MJazAUbNCUttsDmoFLp#iM0hGfypmsI1gAn{S zJbVMp%yl-z!#5-%UO5xc~3ZnM>21NwQv60**xrm zg9AV}tV0G205xznEX>0y0KjkW!h}g$BFF$Z^(~h;JHW#@$ago4Lk0lAh|7R9(1Qm601LPSGQ7fp_f$NHLz1KR1SmoVv;aMD zI4Hn_j$`s||2Uebc@~dzYeRU3gTZWz0|fv8eOCaJ!-Ehs_g}MsIUvI{$b&d+LpUHq zDPRL}1He`z!aF2`Y}0m!k2emG+jGs6F=zt51c&gKYH-JG4yaR`OLXJN=SD(41|2nV}vHp+!vZiZxJOlw= zm%}`y!Yj;!IA{Y!IQcx(gEnAH5KO>1$OAHTgFLXp47@`--~!%#0SmkXJb=Mxm$^MR zbFjC&y9@D!4**<;gJ{n{IV3|2P(v(*!#1FRC!p9mpo1#R^bB-EI;2A~pa1}T0ywP0 zH{5jryn;Kdf(~p$s<(86hw-~_Jjd7Yh2Jz+x4DCFbtX5!R+n=F=yh3xnnsUyPxthW zOL)i6Jk7uG$8$1iGxaAMz)PF_y|A`C+p_=!0LgoDgx5UMCp`+^JXq`e&s(!d^Sm_= zKmv#~0+77b_w+@#wn)FU0Tg}AE4|o{eFys(*t9f5r@fi;{y5pUz1v4{rmMZ&uRQ|2 zz1`nE12g^H*YnZiz2E=+0PFqU)3dJwzTqD}{k})g4}RJgKH@(<)LK zRAYYSTmI!sHKJ=iqFeswQ-0_JKme?_%tyZJufF+?a|0kY?8m>^lJ4 zvp(Ra%MwL31YE`ROv1Zk} zm1|e8U%`eIJCtc5U0Y hap%^(n|E*DzkvrAKAd=Qm1X^<~!H zD^_J@xV)@5EEE|^V zpm9SX6liFmp56onc~u5|A>)}SvyV;pSDcBj4#!*E+g;z2S(pGQm+J2BYh_3PoF86- zPI36ejFjnuXJ8b0fUp35tdX>n_t6nhff!LwzNybG07O@{8)1f@=P$mf#&Bw*U;yC( z9LdB+#{yn309uLJDoFf`(-kHoJ=-gdz#*kw)n_|Y2mX8<|_@Uw>=;zQNL4W1QLap+>Y=s}Wn&*DYz9EJ{# z+f@*-YoOuN?wE=PjqTCQ?1V(^;cDp%OqR)D(KCP;w9d~O24mJkD(09;0n+mU8DI^r z1pQ{rXWAAI#+(dO!1kxmm|Vlyb2Sg>H7kcLNhijcf^INwAaU$#@_Rin9R!o|t{16c zV6;jC4n4;wIP|k`{ouf4hpD0KF-y0#*KtXj#M|hbf{RF5#^k1<3B!E6oD7AQ)&Re- zC$m&cvZ{G@e^sbgwBdm22S9!S21DpefpQQe+i8Mdgzxp8j~D0#0*Zrc?G-D*eEby` zb+c;=LjmF|I0)L$$j?7UfsP{Zxx!feumV;jAqGu?_j`wOkh7KTD%f*J|7Hc84SW;T z75mYUB4%0=hTsi3Fx+1xk`d2plna{;aOV?So8qF4ftwNi%M5ONA2A1s3nCVh9a1}} zg8+{wUL^ka)DA7;$6yvhJ}AQ=bf>CHW@&bI=E&s}}AG7~2a-S~&d` ztfOPVIzDE^aI1Ii;mm#b@9(r&X}N|X&N20(7;ns@w51t^H2%df;P=^F+WNy)g(_6; zNbUZNI*;C7SwmQLY!}6-5!HU=F-eSUT8(~M=;7Vy^;MOP#|`gSbDI<^AN#JL*Uh!p zy{X>GsZ8RXV$%a=uU+#=?FMTue;P zTWxee!{xqD0ry93Q&o5X)T_=&QLFeofeK{&5kCM50mLgP+C1Ks4^g5%$McZT2th&eh+GB1C&Xl7sC#~`L^{6!kU~U=C4NCA#M~evGQt0jNFq9qs~)u} zf_lZ}^v@EdBg7rmF2X()-y+CWfKd@pQP5sQ!HsP%=r*Ikij);zm`gV!)Cj5(VlPBJ z5p0CxjnomeEzmxJc7gy-<0*;3)MHDd9v&pBH==<>)`PA?s)DKPwWt$&$*wijUIlo9 zB;Rw&^55uf!i*Z(welkC2G9++9iqPF>IChHaorDmVFyai6Rsm_MHYex4|3|K5n{}b zs*APDvctQ|)amymiZ7F8A#U&WP8XRZnI^3vu_0eZnnB=fseu_$py>P<3{_&5f4AmG51E~g_zM~qL9OXQl68y|X@bRd1Oc}R4~;ox|n zI&qn7nbbkGLd`C%P?Dy=Ls_3BJ#H{=A_;rQa|n1?-Pzfh-b zqE?wN&r70BF1W~`0x7Rwfl_g;&_T91G-fXPM4BtJJE=R>CugftQkhi=R$)q+R)x1{ zy@so-q<~G3R>!(oqitQHiOyO2uQIO)ucmj?8{(tpSuU#+s~2l47B!0n3l}S&SMB@#{)|EEcCLM##TTh2> z`?q8JD>1gX-&50LbQ?Ccf4x0X-zA=;F0e1RIn=r8aK~|NI23V#anZThIJ$H6SpB*6 zM}oLzol5OWjb*1~b+fgzK&M%!Kk0_)DCst|Y&t61#oB6|x=zIG?j1ExmJgoB{;u(E ze}=tN!(+$N!~)}aBTtbzkY8o5?wg;C-ECg39S+?{-mV`m9a`^9-PPRqTo@h<+^!wp zPp$qp7r(-l;*Vw zng&4j<@Z?z+J>Hl)CpGzfswaKXYiMkDigAhIa!|UGfXfDsvB}(@lkqtzXU=gLimVy zlZ3&9YvI2#jMG?{EaE4ICl->W%K2bfN%kg1D|wW1$t}W2X ztmNeIejdOKVOC*^D?v~~Qi3aX*Ae|jt;%1FTeL0@v?B9Feg_>1ZSY^1c|54u=aagZ z)=XVay-M%q>*62aE~GK^8#%B(?3#v|-b{Zbq-L`8UH;`FNRTmZ;S8qBVBRT;%W=s%TA9GtUau+3{A_f71bIg9ktdPQ}36zcGxIbQtU13 ztomEUwV*%QnG~5KneA+$);6mKoyJos^qS1gTQtwqwSP+*tcRN6H#j%AU0*KB*2+5? zoQ{vRJGEV1z%Oem8LBBZgg2Gyj!(B1(e)ydKI*C6jtP!`2Nypi6$@1we zf-BEdVpq>q*j|cToV7QY4?hx%9p3j{{i^R7%PapVS|3{~r6`S%jn1Ou;dLUrp6p$F zXyBb<&bZE%;&ClBc9431oxMk=2hrhJIot4fD>xo1k-AEi)pF_5@*R4W)Xr4exaH6O z;@P^|)Nx%pv>0G*v5dw==9YE#aLwtu^8M_Oj>A^75!<|IMRh%&zASI)xU#!?_&e48 z{-)E{wfi24hk%#FqwJyn^y^q*h@a+5VdHSq`OijA$EE$`{yXnQ4!T^BT=xSSZ!sUO zXUTU}#Y}!}Ie*>v`aR{0r|v-)1|G$i)N8FZ{gf`A=iz;YHG_TKbJNb_XlAl))7F(Q z`>yuA{NilkGv{?Ef0EbYoBHe6qtf|t(9BGTsW+kb+Q-tK<$lYoExee6nAn{z+$hg*P%%c;0}XTN#ss4 z_ES6`z~CFe;+%cem`K{u2|=`I;4@Z2-{@$j7QlhtI}!^M6AmlW9cuSy9X3GLSz`C= zpit2ByS9tLV!1EM2hBIgHL}&^frhKq&p83o?$>We001=7e_uceMUoo;03Z-^WpyWY z8EGy}LLdRTSZ|-Jn^;^W;+StbNhZ-LX69dnGmifOV|A*-R&{Y3FnjCCQ|5NjSNdAZBKPFsq z4(7%`LHZX8K1Lq;|7+~O=kw72i_`yz+kb7!e@1_Hg%65{{(tW<9~5Q2cOn3Q0Dy#u zpt2j_g*Lb!%Fz55-Eo#9SWK4VG$sloa73B{A}T5>L*&U^cKCHMrAGmxiZ~ZOcFSjqw9NM}EXrjsnNMOXGmJZneuf zD;w4SAph_W{AOG}M?J@x<+N*Z5CGq*Y&w2)`3G-e?SG(e)T74`7q}CgRy9strv`RS z3-+vZYm;0y`M<#rUYuF~=j&a^#HyjqO`N+@{5-RSzlF%oppL!L{B16v&ox^t*}z=j z86@CNxVDKGXxSA1V2u&nNv|jAkCg3yNq4Lh{uUq?|D%;W`H$tn*3w4F4-`l|@Pq4= z`J?Gn;PmsvZB5|J1HMk)?C{w52h9?G7_>;ZM9L=p$9<-M?k9Mv*=GKOG6}$3H*8}z zbK&!xd5$}hM?aR-9Inr-7k*%##6N$@)@ZpD{^Q`-KVKxTw7abTK^BQ0iW?*yqU4f4 zk@cre|FNVq)>YXe^AD1Z{ZPy_YB>=({TDe>#~(}7ZLW{a|KKdi55@mKXCKlmfBgC4 zD@R@-xd-`m#?wo&d?4u9KxrOJ<8_{|fe$vWjKR-WT zwQJx9S!@6dewp|<-cR-GKhhh;?a|1{`F1$=tFdU^^t|yc>RFZ# zoZmA*K|{H#gE?Mw=H#qAd`Pc@X= z-tgky7j%YM%K>*%5kg%fMPDW8?EENMjNt1=&G&L=8Wbej|EC5Fbg1}*&x{1j$yU71 z3Cn_*tiRapWk|KIiAkK+w`J#g-4RFtiLbk)00xpW9RdnA zIJ+qru@@vr8lb!WL+p(eU?JtTWLuP~G@;O+EHB16Q=-g+ujVdZRR)0FJH{0oV3DP& z>w_#2*v@Q5j7FmqOkt{DUsX4<^TX>!v~lQhCCaa%tEobqBFROf!nEryFMil#%T~Dy zgG%b=P+WIErqpC$YEF#TQugaa;@FSwR;T#dkE{~asI;#^lw11e4W3LUJ>Yxe_(JYTzj=Ih^FP;_ibjMYK?FsJY&c)FC z>>RT@y?Mb+{QKEr|DPMyygsU)Q?ykGC+A?M+?syA@z(7-L#amw%h1qs#omq}t!w%1 zofw*IRRjKp^>wcI1EX_=i2bG@N#_=p`Ly}ae-!IXrZh-OOb8h&Xoq8QA(IaE*Ai^& zpHBd3UQHOqqHqG_`E8R9O!Y3$SUIwj0DEpyFjx)D3Y94cG&KFKHJb?;+K~giwNRH- zNMBdm4e{F_upz{g^rtFRI1qE8m^Dpd@VId1cE5tUJ#e_|uvPK;!l3R{W>AaBcSIBc zJswWN9$t`tNlyr?uA3X7Xd2#Cuk_7rK|MAF=|Ia;sj}VNKZXQm!@lqu?@v)y63s%y)_ArCJZH8}#=dGUF?IYZ5j+R4@= zI%pE-@x3LtGd$aVsP!vFBJ8ee;J&sqcn?d`X<4|{8cLygxBGE?B zeID+^bdG5e8Kp3TmAv(xh=&IVucoG~lBOTLc1FBA9ldy5Q$NQQ#n$Tsmg;xgufzcV zx;o*#{HYh?1w7Hf4`g3A@a}CVlqyu+9)5gFxMRJ^rj>lhB=(~z51{w`KWP&%;4NQK z$YYqMITJEcz4X*A<=32$p|h2?wkVozdIGuAbwsO@^8)h9;6$vMB@uT_$_=WXno>9$ zU(`8X=73xecoDb6Z-xU2&viE)tW=(Y>y$jK_x2!-r~V3op2WMo9-W=1BvsW_W!yDF zCaNilBWWqsy1Lmotu+2>nnGu}V%~?o1K_aQ2frJ@lKnJlCOGm)EX~E;DnaiOV)YEI zD6iTakpezG8Qeaq&Gyy9vfmB#^(A^qXMZbLx7nW8mc?EKW{$uG=?Wl_$#uY!tI-O} zV$OD{!GpYl=3BO0+5Kr4u8FQx*qMh*w8a4A?*Z84c$Hnu3hTRVbz+4w28vs>U8TU; z{FAO&_!d#E>7sYBs!#EYFJh_G-_+!9WZjOy0|pBgb4g6E>x61~)HGd99f_ai*k(Uc zjO^1{rGIAVz0Nm^5?PFx(@&tw9nn7PQYL99aSWfTV+4mRwJM`^xm`$jY5_tMUa(O|B61Je78~@*w|m#i=ukdk9KBT1>4l z+R7_rZ7Awqgn42^qZpeI#UpJ)<);y(CFR%j)Eq2MExL6q2Scu2Hsq&t*;PtRzaU?>M*>2uMMmMoG+pdG~k8mxjrWQ6fVijIx1QK>} z=Tp$eAbCqQMiDSd3spDRVt6#e6`TZ z6v#e7AMhu3w@GGvb(rX|^;VKFyQD3fgTWcR%EB|7ehbRuv(OFb_=6}1P2w6P^XNl)Cx5H83y{h;VRaG zr!6nRU@V^RdHr?s>>^~Y%0@#wl~j)A452KiTqwTcav}t|Dz75D$tJv_^SQgfAEE(N zt`7EVMMHC=KK99+)I&I`OpRm z*i=OTZobCJa155rN_tX9fPYXzPE^{7hNz#P1!JLaV=ghqgMGR-v`8LG$V>`X_w3h` z+Oa2OuY<;PKR#FG4&tzYq@ZXRF278BiK>c)T9ti}dUO+}?1 zifX|rF*rg>$UuY?)67DPth1;}_~gX&@smCIofIx9B@W`~SQB$u&a6y$<%HxFD7<@S z1`F)F00OR3syzLi@{J*}(^GQ&mX1I3Qwo{mn{oZd>8W&mqVKUQiZrHFY+@>&dD(A^ zNZ{gt&S@jJhJ%C@yx!_U#KNkOY|V4AaMt$EO+~%I<8p$a?|vbY&EbJ`b$#AGIjZUH zZYz>W$ftX1ou;#?W2+VCgO^X6!;$VCo?nNP}pHo-g_BOub(WD@HO%93qXH~bB@i&Y6PI5H-X)DbY#7qV&^w`)K z1RR_gY-+g2+cpP5LKw}Zs0}+P4<^DN61BWvUy*HT#X!II_2M;>mB&5T^C9D5!i_-C zD*)1T|E}<*%N6lLORfU_vRIpuUPkVMtu8g3>Lf+ z%Z&hDiYM5XA@|UC@T^A@nF6bkiAjH7AE0gbD_KCR(CqNj(r6-C?S66}f%!}hFNeni zg=<0K()_i>MU~Xbk;fu}^0aJ*jj4Ek(ff()`pE|q_0t276J-j%H_ zJacpN==pDzb||y?UdwfJp#DEa3yJ^EZK>qoNoQdJiOn8uJev0QWj1#eA(0ExT}dVV zfHKZbqA+|FeNhueXC<{dkC(b0O*LUY-%_-Eu16DMd%WzgGS6yj9B{SyDKXJaynx9ADI*ra?(QA zTx~(zJQLbs(h~S=#Fc!?kZ9I#QWVnf6&0}@@EY|2bg>d@;(SU!G0{g76q-Lrf4`X!SubLYKfwbelpt5M8PG5Efay*w27fvsj9LD&*C6_9 znx0t}!Jv>@BBLtG&{r;SbNLL#gTu3AMMM7)Wl~ z6Yu%25AHm&9JR0qTxNp>61S>U&Tv63@D_5c*05nRY-zKZmo2SM55*7?oY|mlp_N{= zo<1Bl)}tc{Rb5?u)BaijQ%-BaNOfP}T(b(v(_qO0ZhrL~pBkX#05gpYoUHoXh*04m z<%qGhdL+!UhX;1UuHQ18)D8E2!~tE$yo024r*-yUynLywqtPy|BjijS&IFon9LZB4 zrp|kUO;%^70N!kQSz9x-hbqGeVgqIxa8!_oU?s&;zY3CQIk7laStv1|S+A%(>md)2 zOs&~v$tpL+N_lZR0AhDLRH0N5mh;n4C^r({l9&mLB!lnkMkBhva&OjNA}vgTZCNw* zIF;vD=^ZYXUwlS8OsZp;RtN*Zh1Z?0!UaD)2D-^$RhpRA#*{oPDsW~=w;~srfryxT z6Xq8f?f0BSz~1^-N|4({!1s*oL3wbiPndftyrBvf@2z~vQnx^1nD=*1B;mopl(AZk z4(GI~;qLAdgh)tAdZ#9^n{X~rA5|feJ#p+DP#yhN{p`;e*qHjskckb^ z`}>Q%e_hFz9n5VPk|QG`VFG&6J<8#73vM^b+SRcM+vr0E2n+8TSxQAQ5YTd>q4G#t z+8W02GIRv(}kb5t!=f{oMBQN~f-9Mea5qPz`g$%0YE;a|P6C*&-qoSV{^)le% zF|YkSwx9t9?b&Ft2Gg-@HM}Dc+mA-t`rVG;)rQ-8T9WCO5k)@FLAi)o5uY4Cj%-J2 zw_D!aeg?Ieu|dGW;0K@@crmGbkf;Ml=6W|UFa%j{UwV=;uZ25AOGBeF5`THJI6|?D zZJrRG*V*XDQrw?7qmqI)4;X|T0OU1h$c%z+MC{)k=-t^>&b33yrHQ^wDIRVamz!BF ztBH9wRW4MgrXSy5s7ZKyKqeCH3Fd?6qR#ORDeZge{c!O&6*&sktBenE#)6Vk!b!^< zRC76AQym07=j{IWQIIzlM~a)L46ZIAJRs2mELLkmf}7jYu_An4esaOZ!C`h`0lP+) zjl=s6WMTwka_%DOkBE$#JHL{zl<&+Wx&;5)Ssxj#el#Rbc z%eJ654g%I1OwGe%yXiZaSDhJTcDG+QjL^;aWa%7}mKTMx;dV2u`oqvOgX5q5TP3|W zWcmWNP*t2>XAXBW^sToQEg*8-HH1Y`51x8@u)iJr{_rNefkEEbx0~mYH>;h;v!znl zs3qjD4~$-4W2U18gQ}|PG4?I8rC53JH0o+zS~O=6Fdc@=`fGBQbIvft0K_iV17^D4{Phk(KQ3TIoN&S@Tbh*S&E1qqE@&+44F~AmzV}6MtQWwaWpcp4 zWvLK(coK8%0Al%^*v0-b;~RoK8*t!Jli+as#qz%)41tNa+7%!`s<_E#jU+1aP2H>) zI?fRd#>(1C*1JzRc(r-)UQpP-i#ZPyJJt%P)s}Kyb$+cJzF3XX-#|w6HiF}YkdkxA z^&kW-e2bXuQF`4h_aJy(CZ=(ndOXE*ib=a8Y&V)k9uP4%Lfj3qL-UJj>0pv=ze9AT zJBxceQ||2{pEmd6Sfq$ZR}Uv95ixMT4)w> zx+8enF_&z9W94M>qknd^9M@Yj<7{=H;?ut%6)$bJIv2qk0QtU~^o`2OiDd_(lM7X3 zw${!TCGruLUCsGF6Ll8;SyvdK4+z$EK)clD{4% zCG}sCA3CgvCVzv)1I#=FvijSMOPZ69!E29nSR@(c<3kD8!wZjyr@GpzPkhly%xKYH zT~`F}f7>$C%id$v_u`*zr#E7Pvdo!(9d^DWX5{e^?L7W1pz<5>!$W4MlQVVzRrKZR z64&kRvBiF&4sW%^n>YrM;_VUFFBHexUiewCb+?+{e#II&-u(?BhGZ7haHc!S%o@>G z4;YG`%NMrteAv6O23DEk6;T6HZaECoH%|M$BS){<=k2Mtq7jLH9j0>&#rfA=~(Zvf%w);+Z!n--4DK9#mL1; zgfEi8URsC=N&m30f^RUmYJb9V2A3sCFLX^vyhG)KiP5!7fLq;CvN0xsZ`;>8M;wpd zf^Nw5JiMwPd@~g>1!4Oal70IXU^u1+O{rA2?}iZAe#&_zp1el=?$#26(*~$r9u#H5 zA+zN)jGIhO#P8?l=I%l^9Jd8$Sh{DXh!_%$7yAUK>@4q^<>dsA*V>FefCM|ZZVirz zf*P%a-xUepqwQaiKm_*Y6^U&%F^sA18hFy@+{v7LOC)vmKf@b~5($?0MpSJzrj%p!#2b_7`c8B?i5^(|wHtn# z!ey<+@4TniAWYhy#*8K4Jw-|JK@X%{DA~OUSz7HnCg=~Dle5b_qEeP~5CZyh!DYWN z9?|~7b2kWTgNuPRwj=>qS{Zts-Xcz>biGWw+s|PQ=?T|6TZ29P#;FjS+jm@cOG>eP zqaBYfU|n*nSfzNNQDlmm8eI`L*l46;G6Q$HBe0T4NXxZ17_PLb$1KmfE3P6Bn9)?U z9^vsF2>zVEeRIn|EhDZf3s~@1dsJ%8h(|cZXHMi_74mzP(ZHS{kU#o%3~bwh`J?l% zg7pFv{nxoRD}WXbF5+4zEf@Qb$$VjR}@T>sIH{ zGIyQf$|pz8UQp@rbYCys6lRVIzO2LP_MbvnAg!t2AyJCA1;%1(k(;chnpGGT+DN4+ z>c}WkP!0Akvw~rsqHoXxyTIJ`2RDFk1F(t@4)&GnBs+$~u&itDEk&ZiZitEVL#fpw z_;HrE`O<|@WHJxtAB{$z{m9tucFO7QQ^Ee@)UtC+sLnGcCQZL&4AgUiq>a0ccaF5+ z*mq*^xFy8a9fW7W>d9mD_qt;HHZ$W?WZ+%dOziS<{e(N%^$ewPuY6XsmT?=q?do19QVPJQE8#FTG!OaBu=8-G0fFWe66Ay$9^dffU_?Q_GsX;vtL?a z3$F`$i_*OVrDT{W|_FMT@)&D zczf|%Xm7+xathfd6`j)#RtUdP;4HsT7PIt`ker>~L47Wuyi3tyww1>#T7-7)Hy8q#)wxiESt`@*+hgMw3XycH)eGwh*nl zHwrWmu+w-wB1-4J175%E{`$ZJDj;>immzCiBWSmlx=6pLzgPq6{5*9%+1|pp?S97X ztI3#H5?xKX4)mSLh!8j7@yl=d2#}T1+&P&}K4CinQ&~x+ZYCI9z{hlI_^qfYGZAWc zfcJOGthX2VUW`(yZv9Ni2sNpnY7!ATrya6#Z>bQ&aliVej)fwzfhz>kp=MG9?Wg2E zm6`8Zi7=_#8ASeT{C4nLfvGUKe@^s#)@srUhz@bYXb19F_*89c3QGA(fM2`G&~sH0 z>{gMxsvuwfi=cf6KFIG|ws+-i#@_0w%R+<;AiJ7zU4 z#Ts)WQ%hy_Xy3Z-is8dS&7!~5Bzqw|5~Y$dPR`)x{^2O2K1 z(B0nl+MCft$641|d1Vv)KDv9llZ_s9Fc?fRfv*_06nzWgnh*;xM{4k>P7@?FjrM`9 z7S6ZE*uj*;T)pF4qmZclalL*Pubpks%l0R+N(SF7DxPR8_LR{I zm)@Y;!gyyZXeJ8G@XMNxQuwXTdpP4qyURgy^)%h^qD8Alixu!(`WJ+n#xe}9I(7?8 z#=emX2unkkojLBBp?R6gx^s1~kZ4R`Q%&j&*57*r^eOsw&u!|Brz}2Nx71z*Tm|AC zb{{XV+%INpsv| zF4SFVR{va5_4;Fj|K{QgCpYtrLF-v9qCCQPvc!c!-QxvMz2NuFv6`RcP5tF$X|7`; zQLb%OYW}z6qRHBdl5#>ZSmI%`*#)jnLN{E78*V4(9Guu>Dwd-^?yhh+Iyewj)6zIJ z@LjIpYk02JaG3|h2|JPxM&kPLObGHfiJIl=AL(?Xehj9shcDRGKc)!7I?Sk=s_*;q zLVO{yIB>$tl+u|W5OBKua0BF9{zFGL4EGR2b$pi!DIN((jk6@1OD2%{b&$nmlFQpu zgpuyjzOKc-#eBbWB-UGObKeqAKqVdCsDrioJB4&9T~9MxE&$|A9jo46$yeRM2xmut zb$s;gswe$vo&DipPB742vpm$n45}zX#06M9<_2kE6AbJ`s2d^fhx{)sZ^r_HNAuPT zQYr$_sx=CootTx;jP^L3b3ofT%jkX$t!I~-F=GY6Wpfcm5LzL{Tn%Z~c10;-)3dQWRX?q_@PaN=-R z;tr~q8b587?RP|jC5QWo#nk4Wmm^{0e-RKz8AKbwo9i2dKW+=tzL(h{Vxfc_*MVE| zy&a7e=!A(#cUN}gy<(0uKe)>3fFO8Q9>*5xYjiTlL)G01_I|n^8!VMD^>+PY3k(_pvJuQl3EIE=@Ea9t5<~RP!GYm+j~039#>_iAzqO8i1#>+nZA9vX);S>PL7 z9|;SYle4YP)kQ5+28fKOH*#=QiDd*zFs~LINf!4Q5Lq+mW;WuswZRM!E9Uv`M%=`l zb{#1%@{dwnoQ_{zm^_{hgPO-~zXf)qIbw|0*%)#|1fpOvv?qL9R$LWFJqNNAsY*&} zK~f4HUQX5vrYc2G9R?i?vC+gra4`=JQNEuDIiJ-7NYE_I&4y^M{?ZnRSLX?I)D>c| zT8;+>BP3~EHQk=b5iCBtcov5TMllZv5*Aj$MZKfL-RVewAT{tA){Csf_t5aj0DmK= zmszsI-6&$3LNKbd=NXgDlktHXLB=K3l#FRqCkV*AZV>l2{2UAW5D7VRVnPCgem_Xg zM`pg?ic=K3Xa+s1%-hkr=uQ=ki{q6BI0zV3S8lUDk!YmT)!r4TsSlNe_T@$xN58%# zq<}#VZgjMGV=iwoy`=5p^OD^?4FwI3N+a?V5dcVt2tgD;O~K)vQAThzv4(wbvb+J+ zzC#uY&J@Oq~jB!{F@kYDye5V}I$3W!urd!2BsUm}PG*LUm zL<-kjfL4XnbivP}rfOdQb>YLrL?;&z#w*|oE?;QqVOUDeo1JkE5Ayxzz6naG`1p7W zNSz70i!DAMujvzNf6}}d>lmxGkkXcMOe8979l-oekVg5Bxpt)@3SjoyEMD*33)Mo| zVF~HRlsO)nK8V335J~zT1h<O`;FIPcd}L&gu;ECP*^L*$h?}7^unavel>=!Jr23wG(yDzCd1_oQlMW z4Gsth%hJ}9lFCNuvRs|xjWIx_Y`+7&W3?;SXXb(`0u=C3@A);=GWIdlQ_YUMjsD633h*C|CZpnV4J4aZSoABoqp9bFMQp zkWQ6ZK*W?dL+D0HG{v!meS=UB;WLQ@JF(O1-i^CPlXYy*l9*@-)izEP`0D^#aqE8%~MGxa=RLZkF;=P*-HP5&x{kVN7w6`um5Fyb;S?W*zk!JC|Qc9=Uy11vWZ6 zzY+_}{kBD$QUKu_B*|lwr&E6>nnpq9!-WBwQ|$Ekxd&TfN#M)td1fh3Ox~uGdY~!p zEbd^@Ng2_LrxRGY)fG^iI4^T?MDW{m;9bj^WqH|+^mXvhfB-(&@3!EZJbqA3>RS+# zED7K65_HKYXhee=eOb8#PgWhS3CKQf$!$@18(W^DEcB>|b|k0BY3x zS~Fpvb)hZz*&8pGYtuBE?&s26D-EVL8CoC7UPN7yi`X~^WhC;5O!N=#<#$5&Ukcs) z?WXfp(CsKaFgo3WH&4(Oqx95ZlBHND0MnX%_y;{{jkzsfk#53U-n{m5BBuTP zL;fM8AN(p^=3O{2lG%E18{2NQZ<@fVJ8B||okdgWIn!hQ6V?SBro?ppu|I`U5VAAT zlYec>$2juTT_K-fx0FO&+a*R=Z^yK)Zk#_|z;2z3QvYfD1>zt8pz))guZ8PG?`7bP z{8wS-0{>EjgV@Qaz>%)~Uim|xdK_(vM~`mtP02-XCoC}8{33gL3bo&RxLzA^RkDiy z_Jvj5{J1y@SWtrYEd8#qg($VIEymVa zEVSY0aj|mGEjbPX-Z&w$gn_++j)u$8PQV}N_rzmtJR|;DLB5H%cjRq;ygCYc+CxDU zPCI=b<@@Ia`y8xCm3+F}3bjC66I?mTbZ(El?_R+NrSslE5HM#rep*h*>W+tj!TJIH zp@w^)ZdgM_UMg{IOH9oPJ#4>Fe0QXMFejtM6)%sJ&^L_x$UKk zsKeKHnFpx8@TNVL>v<_B?GCd-vQgp3wT($eNptq?B9P0y-_o2^wW^i3N`)gV%AMwL z(QNjfW<{D{^=SoIJ=o{$-T~x?SnF;zOf#Fz#s!UkAGjl#mn~`33I)&9jIkiic4Q2b zbfP1eFG;tjWszP7)Th^;jWS4kULD0Wm?AJ)3u-E0maqKXoSv*;Osd*9JB9FOns~{p zhkfSBc=5oG%iG8Q7~o0fS28bCUM6Bq%ND?Ku=B!R2R5z+v18FsuZZp1q6TKIyNU0_ zkK_)|PEWaSrqzfYdh>KRnA-~LrYqleXuZLs=K`Ddc%%1(l;{wF*Mr6$siKthk(Qy_ z~YR$w%jOfSP)uQ!PsnE^Cg zX~~5$7*ASy)sw~oq;e#bQ_uJx$!W(VIFqoXk6Sq4J|{GN2v`Lj?dYa8!6BpOUX zXB_wQH;eDIRK0cYG{gItmD1-jITu?&SnCaOfYwp*1dlIZtPp zZiPHiWku1TL47a%j(v{YpzSW3fKyNwPh3kjR@RIthV8uwg-ALinx$N^7;nkht~GuQ z8nst>tN22LoG+k7Sok|BNreJ{B_LwfMB*F0cywl_v=;1^d^3*^>Fq=?1`%E`YFY)EObct!;?lAxkCBx zPA8n!Gk>*^=3ns6Jm9uttGX@^2L`sbkusHPdFQL14Cnsl6tcV#u3O&FDLh~1)Ayg_ z_v!?r9KY?hmk}T6i}Ehnh(QB3EBnE>s+3*hkAJtNb$Og zHATYq)oG&gE%tVSxv8ONmr(7P(o>@Wx&+z?^V#}hV1<$hnS_M#1h8D9ZYI62tY2TNn|mGg4-yn%S7{f_;F5M82PDj%^wa>Cz-TQ5oyC~kcaGH z=hC-I6ZA#v5|}K<@6=729SBJ9x?~sj(`W$+sd!L~ot)DJTat+E5pQ35q}d{pp=OQl z5D5?^x>IIM4(9K%aktz$Ivfh9g@DfO59f|<^n4HIDdl|ZIX@5A^H}(?Db3p;VBkW* z2MWna2bt$V)PNs2QiNvIkJ#wKBBJtGGz)|}CW6XLV3!9PCdwM^glF)&=IT|L#Zcol z=WCNG_6`p4kVN6lz9^<91PR}#Bar10W5G*}X0=JRCBSA;&7iu*lUEk=(`45QHJS|n z9{_wngTH_Df+r&(^C!|Er5SmvB~c-*rB`-2slGYUs7CGFD*2@Lh)t$0;g zl*J>}1qxI}`YkWcM@CK|y|;xcmyqe1nQUFdDM$4>vMmJWN_ig%s_lDsL!h5Ga?{dL zT*lRqypN3c7fKc3ap=~$JzX|3>H_`P+EKvVwRsgj{Pb&N7uBFc|8bad zpuod-f_cg^BzISkb7|dB_uS*tUKJ z-uq+`-3tcbA%0N>M&<3>Hi{m&oawaN z7GJ*iBDT4P;??QX=(3U_g$dx|clSLy)iI;H!v~*y7Ja+4C=Uht{J8BLahA$YkbE*ncjZ>jE~3obAcW3@4Ihj zgk=Y~ckGW9zy5$PR_q{f1MT~cz<0wY!j}_cX5tBa^8R}a=9!FEo%`YTNjDBPUu(>G{#E?4{A&i~+zMY`ALWWOJtH5ZZn+N=Mh@U)W=qU3 zqeGn~_~eW4=uoF6o_cl`y0&ko!Vr}fX5!n$i!lE`EAhfh&!K0VKvXeea|quTORhXN z(~s~6iJmdVsJ>l#3l5HT1uzpVPO$!034%}Zi(CFZ}QAKGfJgODiQJ zD^?>VF%H{z?u2dB2+X*5Dm-kevEV=NU>Bnp54+|jjOp7RUHgy5NJeKkv||kceKCW8 z`Qpy|9zb(1E990`Qd(w!$3liK@(Lhr?O;`%kDq@00r917c>1vi;AK~Zg&(|w9SlV@ zbo@;WH{XTeG!CN&_Q0{7Yw^*-#W2|W;jZcT!_zDW*WGqM#ti9(6Z1 z=+Y89*RH_gA6CMzc_-!H)w0?S_uYFpLOreV<%0LIVfQKYrLW-|M)gBEkbF%6K=cfespi{OUL6yaG+~PLwS}8cv)1;Af)uqyM5OlZnRPbKzf=t4@WF% z|Mtgq2#)TIn;61xBpDYj)fEHHa6dL-gajZ}(1K zXTzCZ=tRQL&qzdD@_*W->tQI)z^9*lisU>4Zkc*7C!p4tICUDv4(^Wq3<>q#Ctsl2 z-WRt|z8%fdkMP~_N4t();6)deUw^&`vDsx9an1GU+a`$qc}tX6ICD{z!P*H5`im1<_c4%hXM#@%<{kKWzdA@SHwyz!sU zD3a8}lhJT*8QcbAdxfdc;77M@W+<33>bVcUTaVI$9DMTD^LYA=Z!l!aOe}o;Y5IT- z#LX?cz?;6g-+tpgtlgi4gGt3`_Ub%FSZIxo{r`=zV+J9P^*l)_>!a`1A;irRpSoxq!GS}}k9D{jEGFUoeRJUN<_Q2hU^mW8fix%Lg z^)aZAIf|C8TcB%?0m#^z2pc+>k2`h%bDw$^KXAqJ+yl45(%y{)i%2t-IiFi ziHXHmZ_Gw>PBN((aaj2APP{z#eYi(@z#}Lcw~g$84&yse60N7IBMtw4@o~KU^L z(}1^T--XZ+Kjd$XWAqLWzQ@%2lW%6U(%H0fF>bkYhN9bcCr* zH{d-wy|3fSz%M)sV|#Q!@75uRNh^cDiyf-@o?jCD)kR*uQ+iSypoUCYGT2cn$xl0m zweckwG3sV~`ECa0f3*$)P8^_2YByi$1!?n3kdR$z5fAKCKtls#r5Vtp-%x^M4RwF% zsHkp%Xoje>o)hmC5b=n?5nk|*_{mX>z7 z_O^#G;SRzF^SV-{A+f|(FaLs}e%j*BM_#~nw?B;dQ%CUO+pi*%G2FZ<(JLRnYJxFW z8*sH2PH54wCqo*!P-kn0@snoYn%n6MnBeHna6lzo-fmj@2fcg_DXss^JI?_s2kK_e+4dg4IBL8N3Az=xi^tP87TeXIgZ@A8Qntkp~vIn(Y4-JQ9s zZ-!lKmtbeFE|@s&Q4G0uDpC?o;?w`UiR0Nd3@zlr$xk-z92ki?Nb%o>j@zRg7%Gi@ zTuT*A7A;l!_aCIp1uNNa25U3q@Bb1%1chSy9Z%rySuQB2l<5=TkJMv(A%5Om7`;NQ z3_?1OL0Pd;hb=)h>wOuHiBUpwGm?;B?}|xNZYQl}cz(`P1j};daf9!E1}WWm;AX}O zt)SC$5AKhappw$Ryc^{uMYOsw$C%N>U|maJ#^n{t<)mg|qBi}gJ`lc%P|$bK2soNi zPoAEL%JzPAP~Tcf#$l~{;Iq%VP(?xyaW;^miT zKx2|FXoM;`O%#j)-!a|06S^Vk8uwpDX%IUN&C?Ieigo8&U2WYL) zDK<%xO_UObzWMHpg{ZZ2W4IfFMP4q$1EsUB0?dBoQ4Ah3kg?QSqf3{*c==y}c;V@1 zkircZUxKOZvB;k?0pt8~VqYS`$r7au_rC1Qg{Zc3g&oT*$j@b*xO8r?jJST zk<|^m*T?|YXHC^h6|FT287f}w2e4C}+uXwTKFsJMRKxtR6v-KR4A?mZ&IJE-J}N6C zDXWI+pE~Mf1cZ(vxsN zcAJIiGT%z^44V$*X)zgzP&>T4$>QF%2 zSy5Mb`2`T5wla+P9&~Eg2DTOkY}>RE#Z~q2_3_1X^Ja6YcQ4lLJpoT|hUwvRvhtGU zwMctP(o+OUR0D<-qNFS@h1?@`ICUx&j*J?C(j?4y;C|fyzze8kyfIIA7ZvwQ0IG&6 z0!gRi5@GA+25UnmH{Kq=ebc8iFC`%scgq9M;I(J&$J>ug$Eacb@i}#u-a%1_3JO4G zez5{uW4)w}gInyE1H&8;%lhpoQQHt~By_x#Syp4ECYD>KKZ)1o&cMerAHe9L1F&Gp zdiY1QfOSit?Ll(!{`?$kASye@8F;u!f)TU749AZlosu| ztmcfxdZll~$|2Y{0P)EQD66()u*6=7Kez=8xq=vZ)4f>q@w>>5KZbgS=y9d~dDhH_ zaNqs+BcJxTX6E%6HTfaDJAXFT&wUuBpb{dN0)(T;i*~G@8pI3B6lx$p~Vj=@|ZeDl>8sPu@&^Dn=GsS`&bfE#dWC--nOcQWQZ_dMzd z`c^dks-)SXP$P5-J;v3RP$wMHlF_+*4JRW@PDH-6iaE&Oq#Ji+p>3PCu%bY)as5UH zT?KptJTUL+C)N8HbLbTPG5c`USIvUN`r_(H!b{P+OZ>mav3BX(u1mbaV-7X}Pja48 zueI9cck~X2eMv0lzVsH}eswn9_;wejKk+J(vL;}{t@pq;iY7XY4jka+j8s1BME!vo z?SVV>9**ss*Q3V99bLI&ykpf8g4(xeJ@Q)IKjm5^o;r-9ap~yLxf`l8j$zBDchmq; zOIk`n5+_V-QN>hAW<}$GHy&knrdndsGw(7qdsj@SUbgeFnGIvOjNE=G4ACYU_)IkfCK5@z<^XxAzn z%RhgYW#(f1kZZB(2+K^$Wg9y)VsR=CZC(c3;7*u6c{IL1w42d_i_x=BPh=$=!H-Lq zpfb7+xs@Yv>jQJpqR&J`weAFW>da;JAhxa&Dn|g!**^s3DJQUs`rFCZ48*}*F~}}6 zL-($o5W9ChUVrvEwCU1=Dv-ypvsE8dP(9L_?O(lgA$BIF;pTCJ@F_zr9f?grn~t4P zoSBLfr{fXi&)9I%RvSva=_$x7E~N?92rOH~4Z0&4MjFTmv3LlRH;J><ZHFcib=% zaYy&#WJ)eNaRpG2avU-1eubrrk6NjTbbTq3n&8e;w%n8SJIPaiHqLs?Qg`a;gf&#p0 z#uSUadk^6F@nb5|tQD#$5ympWqCb3Sd%I)9&v@^HFVLnljq&$vLRvu;d?*q7c(@@g z?kK)m_$lHUJ=opRhLYb=q~#P-nsrgZ3(E_#aOBu27|g7d`I$BCb>m}CF}!;m4jhhU ztTYz{(wxY=wgT%`{fO^ZZAOqi4@xkSZ(tDhruEg>x8+xcg6B>+C1eT2X=P@>rZp?^ z<1g!QaPMvuNaSMX_4RT`dg4iZ@#$wcMf+SA>VYL{f&-VnwvXsjcg$M6{oVq21o&e2jvb(JvZBF`n`zrOt;JGWJ{;Mq{@Q9K{;_+8;X>Tv_JXcz~}ev*v4KpN8Irv$SE#^ zGbaRlS_?>!$wNCgA}OIob=MbkO|AcQcKe13X77Jd2=w(LKK_>?r-bUQ0+nd;JfY*@FBlUh3M zkke6AS*vWIkDfTqjRIR`dv0T1gA)uNU&2Y(h7*Ly5Mt9@%b0$#u?cYZ3xWqjz;EJv z^6sK<(TVTl{+JD_uYAc5FEbRX zklMD2rVcTehX)GPV9lrgw6fNMA$&p@u+j#ZG~~}@>@W%YZBHd+375GlbT_3DnXEHt zq@Kf2<32o+oGFJRxRdP7-D5fCYwhd_4;M$3uZ#xrIowza@Mo||z5sGcEh9aH#_nEl zXP%0Z0-TJEgFD0ZRP$JBHLMXH77S}j-356$)ag~hfq?1Gm#D6~3@1;Vgo~#irPdNI z)6EeT5k`G4kem?5Wxh2$UG0(1cKb7&x(8J!bp%~I6ug(Jv_1usttuaHSRwhl^$_!R4(}9OR*v6m`WkX8Y9chX2C}rebH`xr#%t1s{ zb2xD`N7O8ZIRvW`u_2}IoWLcZ5*!x7O*wOhx=)1%CoDO7@F>_KxvFWLrYQx7dsk7eSiEGB#@$b_4h9~>oiAKzIS{9+cF$<;;)%2F-8xc|tWLoyGTj2}N9 z4?XmdDqOATcqOX|S=q>U`IEdd8OpT)owUh#*v6Pw_$Wz!lRWagA-8s z8FrkQPYFY{j+O4Uq9iQ9A$l__>doY&Sv9Q}WHU~dz_NQRn<%0pkmuzXsDWlbHXMW! z$yP-O=8Gd8Cj&x)Ac{mHxL9s%lv8uE)RlV0 zi@%xLXrW%0x;c4VUKFWAuGI@bdSn@@@^W%fY6F$mxM8G1os%A0F+U>msF#Ix8 zXt}|!8ZE*X@k3xqkpFF&#yYj~Wl1ikU{a=R9vPR!Mw2~>v@1F_X^(_97di!qgzg#w zhww(~6n@M2l1;eAJ~2*`avWML5oDvyR`|?vght_$ltK{i2EpR@h4X-L+q zd+LN-16Sok_$coZnLraoPMr;HuCA_8?}M>_s}-*$biMSu8q@+nzj-%|U?V3lg;%CY zy(jD^;gcM&v>`AEpHyH~mLm?J#41JjCj5{IP*h!PoM|x^?OJ$QMn_U1At4w(d^i$$ ziqez&BqK(QpgE=!PMRx<&JleKxgJHvlE1=!DaU)VwQ`NPfA594>w-@ZiB{ z*|O!C_g3C<)6^)loBn#WUb9o=<<>w~*dXkZfh+nmVV(jw8N?j;3Pd?*1au|IOD$l; z;i}Ajj5D@z`6Q#FTJ3H(m?*KcWj9_bPy@B03@Jx^7id5y-z7;N8Tdkj=spF^1h8f6 zNd^{gDO!aFn@*d_r3q1o6EXZMLLEsbC$))q3U zh%Q=ziO@y>lJBzfFW@ED(mz6h0&1Qv6abP-pe z?}qrY_&w-KUU_e&kI4+x7WF}gyaykC_#xhZ|9yCSd#n5cnlg#X#4vyU ze5wzRqhG&%1mnf{{`>D0ujH8{M~-0k?%jCx)mN2nc;?KR$mL4sz<~qk-McqWCi*Ix zh5q9NX4$JT-TG97^B;Y4P2lEEj>YQQdK{a2~s zIho;AI;)&Bzst?D^C}2xd`t#1SF$QyFg^cenev#_r?JMgzO(N&kaXS;;oNW9c_yck zr{}t7>^oVO8Z(>Lf9COqi*r4Hb{_d|Eb|ZE2llrqXq%RC=Gg{<8tIWXh~+}#J7@ab zU%fWvx#_dU`Wt*=@J3_(rnxTewE&-NW(^!T5I5dw< z0#!Wr3Y2B@Z0xvkNT)m@1@-T za4$mgg@%UW=9_O;lf&Mmsqyvvs_$6If{sU`xMB-7H;@bgbUQJ>wM0)SB+ zV#;3~crWgIrI)62KAQG#9=4`s~4C2P9taL=JsF6De4xv_g6Z?9{0f zH(CP}rJ@3nB<1DgIZLTFI(F=+>J*7xt*-bf;3{;;1R)cLJSXY}NdmC) z%tlJ$(oV^9w#q{XUd1Z?ADsg_2mUS&hy*Cor2v%t$+bweTefUb03|?`o}Q-E0wUcC zAW9wqFZt6}i~@rG^q68Luo=CU?NGT~PN{Z~+v!~LfE?Tq*>(ct?<%T+7A;z+`~q}xUju9TlE_Lw zhmq9tstxsX0Ivlz%u}^C(SNj=;!@f1HqmD5Wa%8Z;y55fKT+il4Qe9Y;grRMTH^2EcZ?SB%eGh z&qzMe&B{iZ)GwQ1(JiCZ=2(|5U6jNs78XLYfU4-995Chk z#jizPH_^2H^>k_Jx^Q}A#Be+|nbcJH@@EW@Ww&fP380F4KvN&c7?(c*S&=3MoCT1j zU2-k=^vSs**t}YjRvOuXUqzp|mmV9R?c~0t*vgJ?H!Ad@j4h`%D zq~*SVxd5+e{ifxL>OuZQ#UXhFoTcpZJ)`S*O}VFED-MYLr`V>79qYx$7cuc+;YLY- zFX)9Q8JI>rpEd|D{Mn0_(`dtMG~&N_rT%XvY5k>HLHuu}UD~HLAkuWC@+nDv7r>P7 z0>}bd($5;uX+SE!$)DsAkP~YJv0@OFfar-uDAV$uuO(8ZmQR3H>eeJ=c}4?n(cKCF zOFeR5>NI`#FKOV2(~aISjPv)T<#1fu5?o8rHO*V^;^6ney_R%~viom%40 z#@`9-f0TrtYI;X2qZ>vJsXxm4=l4wb^5>cVC`V&|X?*^p-2e1Fp;7ul!0!LsyAJrO zitPQRH_}KUq(JB;R1xXYf)pu=Ad2pSt5{dpzhW2JwV=D!wYwHr*;QF=t0=38qApb+ zp(Uge64HC`$^ScZ-zASoC?UEpWajrv-h21X%sq4F-tV3{Gjl%q6tFVESkB3Bb3|+1 z9?2trlH|C27m${9z~W|*oo52pXPV49H!WLtjZ$>(tW07CV+U4!Ek_THoh|(}{&;^$du=+k#T&=c zK$&zC|7&vqwCVO!xD)SOTbI@b<&zGtt*KHEkx->4Cnn(Nu}tm;V_+N(k28;@A|Wx^ zpc>}`DfgT_K$Q$`Bdo*8WazEruwH;tk{XKhW)e=f`1p9TClsnJz;aF=XbIS!o|=OA zghUiFe4*(xm2JX2iOjSVBqSYC^zs$u5-6Njt6De7@OLHojGh*UjO;vRoeCxhfO7DM zyzDF-+P4Md z1iuOI))gDM7k%Zlter^NUq~)G(m^k)%YDg=TQ*X#lFo zD9MG9zjl59Ev8()7!Tg{dz2;~U@T{$IHIqS!_cPG_W9`pdkQx}YuoJMmp~P7=!fDSz!PX;;HJ_L%r{yczvT zB4L%*Ib;5$NYs|*lbCTca_v14Ib}KmNHcz5AA@&f7Nd(l*@urEC688r%%3=ooBhkM zd)H3n7gfQ>s}qA$hoY3M3GP7y5IMaEvQrZAQ}iMDaSymK0aw(yVA3VC8L!p_hY#*! zY~M5vj~RK4L9z=-!9G5c=iD7|;J|(~IJzq>Pv;S39*6sJ?-~#L$a={w@Ta z0u?OW!Px`-hmJ%Z7p1@X#%rjjtkdUSi@^*O5)tBnu@kRD)gkWup{qbF*_oGLip}LyuLmM0!#xfXnWjW|Uz0T+v ziu5D#*u<#uobeHO z=fzc6@yrIi^3S)(klPb4Jo6G3U9$w)(cfdVXD?hZfU$uYlJNT5mZR>))u^Zhd?&ZAABQ(%aL@?AmV}Zd!5$x#nEpF>E}R-?JR=ZQM<2AqPyo z;u=imr?(I3YUW*vcV2xFU;MBO!zaun`!Xr#DZ4O%TrqbRUU}{>IGA0{mz1lR(?(D8 zQy4nF`eqB<2Mj@Ir$+4j=>YlCB+wAIl+u#TD73@MN1np?5&ao7jut05$Tohs2G`v3 zj2d;=Q-_&3^<3nCJ%;w+0)M(3e7t>BY~;z2yAjfRAiDZ_si694aZz~Y>8DY|m$Eyb zHlZt8_WQeV0a=TM81#3)za1aE^E|$&_Qcaq-HDz-^w&1fO;vv-K3~5E|M>7fu=5PY z|E+jJ5r#_iFbP03eaAO=nuM1%ZvAOx8xuQRgd)bhPVGPg?axNH5v8hooI{+-;%qp% zdy(Ze9OXHQ_~V23;iIn!1mhwxyk{4zd;4Yl>CbPV!7Ye8VrC)3B@ovxz6#D28F=uH zrMUO;SK%7a16M9yhy&XHx8-ee%g$??|B&U8RfX-(m8Oir{%Zk8Vv5)8Eal% zg~dy5M^a8T<}SP%j>$h@_QIu@c;O)O#l43IRz86vIb|xaxHAL0PrK@7EWTnU(qp&c zHw)%t-Iv>N;lvrF5Fdll(=Ws9siP77{pYy%frqg_DT~3n$@199C|~jDjH?S`z4JG** zq_a2YkHdB|QH8J8%mK$LzT?uwxg2{f6ri;8cNC_uPU9R=oZUn6vO2EScV)t371fDJ}oBA_mIu%E0cy*!|tVasNYqL|ith)@9Lu z*)jb2kq7X>hVRgO$SBO6Myr-?4hO!dJA1n0v-R&IIxdOvcyqCS?HX*{k%mX^y%Q1L z1Mtz>zv01^kK;&Q4X#>p6Gn9NK;+!3FfVdE4s81d_uc;h{_|rL#!Q`uo0i>%9r3x! z6=7JqHu7+2F;1%iZSkH~MW@QZVkaC8M2f2ChAmB){=fFLYl;L+>y$o^uJ@BG& z=r;di44p6yJAU{I2fofka$X%ShzLSTS{nKW^+DG`b8*4I{z#ACi@R>Pk<0=N1Y+L_ z{d?a_el?$9XF2zp5929ksf^5w8IJ9>gnT>B%?Hw|5Di+TeM89tr98Irc zKyPo-mnY)&ulHctk_BXXNW+_J|Am_$e3EevE3xU5b@;!Pe_`2R%$s`&yj|U}?4B#o zr+X0ge)B1uy7q%FN|BgCdZoS*i0B`Ncm|aZBh9)q8H>f|?Zfs=n>8DaoNSb^nlicw z3JyeBW*jQrM`FV03rG^0hC`$;ioAFb_8&Ne(Sv4V>Lrs1ys~+R{#AmgxId(?7F}-y z_3krj3I+sw;r&;iz_Y8r#)#BPOr9{7j3r%BTbRk%!F@Ry=YX|q-o%{6OVHED0UtiH z3f{LpfgycD@%?A-U>W)SMh)(QyXb~r|N5UWdG;cB^&g6?_&u06XAy=>z8F`}TZFBo zY#Kg#A}(K8irPJRKLjmv{Q{gvW>EK18lk1>-l)XS4}E(|Wh zmx3c*8SbRVu_vF{>;+4?`hb&HJnl-mnC#p_`1S9Lyxbf(2aLz~9wDf%Mpwo)|(dmrEsH5B<^4o5a^>Oi#R)S-6r)Uo&YsT$LrZUd0?2wE zA+d&qMIkcs5>yZ@WyOTJcLM2>5$1>pG9~vNaj|kM$YfP^b_(j9y-0avthFp7d$J4V z$vm2X$7tQ#1%&WL(1`fB96bE=pV6-~T?P@on4h2iAy{_fE%Y}FG;?HAT0p9#YJ~DS zBCI_@Tt@W`^dC=|Fb;Oqt2cedHC1GZc5=h?OJ|czliX!uM{^R)f#=046>uChfTIJt zab!(#w+np`#FvIl45p_Y!FY~9B0@SLI=4XePhd!Q`qRnSk#dAD;fpY^-#{{e)Nukg z3%v$#q}7uQ8q}GgZw5E#3qb`t7r!>Ge49)*D%P*5D-FEos%_rfVr3XNeuE0`EDRHJ z(+gOXmX`6Ml9d4jj@l}8zxZ}6Te=8E$x(QD^?TSFosMT;eHMPSFj0|f0FZ!8bvaiN z$U0N{@A$+PlNR=&<#(W`pA+7C^#y$Q?RS`a(}TET@?bP_RYfg<--Fu}GfAyt-z^x8 zqTgrB^bCG)1399l@s0KZP5&L>6Qw6NtQ!#gz{doLe~y zSzfix-Vt3qNl$+u2E%(y#w8QGkkNM!KHBgjh7OCsbiQn=3v&>?HwqW{4N_%TR3#Y^ zNTBYrl3ZG5-35EpEVRu03ums#Xg-IkjDQ6JRaSaP99iMNN@p2!re0Ptlyf6RNu8w> zbze{2HgE#!)3q<*^Iho}K+sMKw$S6Q-ls3?%t1opIKx8m-VFJTawqJ?THCqEmTV+!#8#NSY6OHgvQM*6juR7lm8 z>@&WwWRgz$OE!DB`kDDG@>{N7&HyU{mh!T$EF=Rnm$Qjq+Lb${{+p12Zl3N?zW#TZ0!ML|g4 zfmpa?AwK)`OH7+Nku1YL1O=MuwC)5%1U!R6L$G7(HdNWUF}hPQ5@HTu-8)~BptFpD zOL`#pSORuO??M0{c%#iqaAh%y^;wyhfH;y}s^w|YB4UD!6a+MkmzL2^`LEi~>pF50 zNrvW=!V0}*+YY);>@hKNI$}S37k_!?Ul=lBII&}SI@Ik_hjn8OG6QIm+WrnWlibHp9ZM6ZaE7(37p&p-DJD&4wZ$#0ip zW;g1Ex-cwrsY?1NQlIdiIn)+n>vl#`8aj?F zym5&B>~9#_FHFwjf@wqW(%b(;dI_-nu@_XV(W~c9cU%bAC%)%L^xZw|vV1M*J-1ggfw48;0hk;56>XL+U*xl0`hq)x~ zSWW?|OY*qf=^(jR$b=l5%oj=>Qj+3O*hu$46T+#oiCow0&dI} zZ5f(t0xQv&xFVd~yiu8%fYi)f`lRRM`wi>h-cU*1@C8KWC_M|{@wX#MAP;OATe+;gfH5Sp^zQY&aeTPpz`~dOC zN^sNtPh#($C_H}8GE`*sOP@L{WJ{Vk z&2h181PDC5{kguh0%=E*kjMq|PMo#pxEJ|c>@E@U#RurcwWMXGB{-6t$PEs%E;o)o zL1+3B8?a~l7JT}}CZuvhKqdWr1w|!Dh>Jl!7u9<(_;NMZ)Mg$_MH($yA^9ukwpKSc z7aU7Cg!St`LQH&;T8EpTmV|wW4s&+~t+wJ^?AjYk|6e##xK4Keft_578cW7q4!ybK zD<>mGtuolW>oB@FRb%VUD1x2A*t=uPH~994tvDQ?NZDm$2a!}B6au_A*F)uVCjQXA zXv8F@p=Wo}k~8xD(d0N&o9J?QflT*n8 zd>G~QQ+D#~getBvmJK1v^iSKvkuomSD?QpJMetJ|wsWk>84OSUKA8_3>0|h?C-D z=~7{ASNfjWG$Q^- zVo^%hhQzdpr(O%Vwz!k07dO9@k-0aSJIFHVI^Y^x+S-OLVz?=TFHcUw8utSyBI6E| zJ(w#ksF&0u$@p~rzqkRS5bmUPmr2AeUww|(`7-U)r575C)A8-rT^s?BTAnY(n5Z3i zll))Fx%KGkEyRsEh&_0S?hfv{W7#;$R8q<1g!C()3N%i0i?{h{dEqL0cgD;WDjhX~ zX?7LMSVkRHBZyYKI;`uEisa?fG^$cnpY&hza%QGem2IhvS+=E59Tu`B&78?`KDDx& ztg@^Gg{2h;>=LM~4*{&4oLqSNbS5P^CzM!MDJk2_s~XWYD3D-UOoF{*WV>ZFBTgQP zKTg0#;s=!QA*!_}^on~3-1m_}EkF&cs!a{@9R$q}_l04|e z1$in~Lx3M+M(~83Qrn3O^HEXLNb*B}z9iVEl=CQGhMel-3)T)H-MXu#V8x`nFR!&n z5O<0d((hYm=Suo|Az$RAXhkXV*%l#CbQH^+*1O28bU~l25NwLIto}Gk$Rf)^en}O= z!^27c?!n!I8Kk|JU1)uUK&kIYm(A#); z`H|k;o)d-f@Cy!yzfY&8>q+BnAjvjr>CgG|=i|;h?^ONKG%;uc0{)63Xy83pW%J<` zkPrZqVXKj3U%gm2oO!oA^#ai1LJ;4ZYy}nnrc8dAZ+&yJMQs7*L#(16u`=-^3gAiI z@?F)d{K|%ZQOcKd@~4yk0Ni}bb?D2rp!JO`L(6Q#`n7oX<4p)8*bB(W#FTlX%kwYp z1d3qD!`~vSDUV_`mXlUVnj%)4_$);pv8E(Gg2*H@=~B0Viuh3ZLj|*u^CG|GmGknO zC)qxkz%$z?^%0bsB|~STCnJ)TlE0ZwDYl^->OrE8$#o35IN8OQfb|5^arvc;fS{S! zE_>B3sf*MyJnkq<%~T&5(W%6TD*6&DS^81(sdieog)*3{FHFrDx)7#jV=lnFq}i{A zUWCp@`axVfC(2(h8#s79X}k1|+!yj)Tpj9u<4L)nWQ7M0sTdLR;%`kLAyc+r>QjI> zB_#z57A#P}E0(0R|5O&`FD1+Wx?a7i;aqz_ZXS6EmfP9{md*U~ICZde02S&^F(pxe%x}~GEA8?1)+YPh>iXUv8lNT z4ehF~Z9L$Xho5CkV4ye(prp2w$)hf8`6qeJcE}+^4nroDMKUl62um{0*U54?o)Z~P z-aeK6XaD3{%BQNp$N*UDOmbe5)Gf%R!U^)bNMXLXR0hjG$!0D8@pH|N8|CYM-bbuJ z0h||A##xK-8LKT~2Of0XjFY&WP~x!NHy1V+)77!J%PlsA@cj ze3&f{sdd@r*FM#`=6TQdcWdiD>vC2vm9v%cWcknf`X{U86vuv6|7qm^S^iVhZIh>3 zdC%KqTh2i!4ZP=|JX&;7%FKKFCZ zbdw)ls zMc%7i_i1pL{|`Y2rq}H|cP=Vbkg>L3elDS0wt9Jn#Y0Umfm=+ww`@3< z_#qGsLL`e6t;I{E+P541Y@?Ieg=>eNIICyB&<4)H%NHuj?<}JGJw~EcmSC zCZA0=WR{Dv@Th2L#CYD*^e|O7@9VXR>Ene++IBMA8d4qPcwDW$n;G=qKZWCSL*jxF zS=Y*917*OWH7S#Hq*FSSR#9Cceqb-0mxjgitE#FtW3Ej0J09y~c|KZ2$Tf@hPVo4i z&4k+wrT4`)Ds`rsfCzR+p<*oCmi*ILo4P zMGe`hj@{@fIihe{$c=hfv(qLG)O3XqXp#ot;>PMxX=yiy6-xaf8`5GyatFNy<^`ZD z6|<{8?>+b5&^Bd|FBQIDR>~FMi2Jfr6z2MF`1YYS&sE_S=7NZz9*=`+AM=f+fu`cQ5xFiOADeUVH}}d0;l#tk z{s-^f~CE{hj;w24+q6H7(T>yQ^=Yjm_8pt{xSd_ny4JU3%BYx`(4U zKzl!P3vDQvzY2sb$$VnM#W(eoNowYzW!u>sBA zSIqd_xBLi=AI5t&GF*9aIE(aAP#HULtp{we9_uSaU#@3j$+iB54~K{^lV-Sw$}DNA z#?7#)&pbD??{&8_3ULAcV*)wV^@T*nt!rmL2I*;o8R06tnWh?6$6l(E)GF7!5jA2B zY1s}mRjbxd?S(5Uyt)M)*M>kT7J0^bRzz7MxWk7F7v?n*nnT&|4~cWFZzs{sX;%q1 zGsnd_Wdh4oZUOYRkiUj_^RG|XE>6ZxYTPQ4WqU@Yecy0I0uAJdnIbX@6JMGsI4Tj6 z+R@+JV`TR+HTtbXX*_-s7$*l177^WAV)T#Pm(VRDWXRkPP>)w$ZZF?OdO){_IUCLg zcz<}0itTz!FDgw+(S@?PYoQhTUtbqGsPVvS`t}HV#%ABU_i4GvEBYo^oN?c)e#xnX zr~Gu1A1J+{6PgIDm@HOowra>mvE&I<-N2z&c@w2687#XMr}DZrII!L;(IY$4zPR8Y zBR`{I8STz>hOGFO@b=b<>6CB%?%Xmzou+04QnSKPy$7RvYY;!|7??8-e+tA~$yH*7C)Y56pl(RrVoT@rVq-{Xi1MH zP7!W)d1_0(=teScjt`8OjMQG6yvuH9|B*Dy*iqYs+(k;O1gO1OE(`AdrqPnK7U6{a z-5z-dcDs2xUav#N=7CJm-xU}`cFiR@@tnM1Kv)eqmp!9;-uHgC+_fBL(Y2qO;X0jO z8mRAyo;5EwGo(_6$GhkBA|i$Zl3vLIFcGbii{T5EDLnetmSGg>GTr|1#rYQbU%ZlR zLIa&ud?8SKGA}ZLJ8_6VL{`%J`clVdhZU^0nM6G2gG=J5r=(Ifq0?OOkN{}thI`hR z@>7$MNj+A2m|!0DCB18^7z}p;XRVT(a0r3mguMg^z0(N+F?5l@m)EAOvQ75If=gF-SU;}iRZ`0*Nxvs3d$Lvw?~8+u-XY^boLgyG~dx^3Pj} z+N_?5E2|u=jRh$`*kd0Z7I9|`>{TJZKq?dr4wx}uW?@xbo_zUgcQE?lg2@}UL{FpI z!%o|3i7>^TwKy2CWr_7Z%%C%nnb})K^B%Gb;P-N5*Q!YT*G}w{`j1kt2kkj038Gqr z#k~%akkU!31;c@FXZvv5?oY*ycZNn`+rgEC=2`&(!148Sw~HOoEw9VhBJPjW*Px&U zzWHZ;1TE^)n_<<24{}9oeW~7(0xazK)3VgIgSR5@!;HVnzt2L2SHPn@y!D#z9)oz~ z|1~*bX)KSo7RR{~@in}VHikMh_YB*QdO;BpO~r3^;hCKMhbCczY69i5xa2ZHYbCL( zL5y|i%^ymVuI>CrNuOF1l*io7Uf)C8=8d;g()v)#Wn-OS-%;rrzygY;4thGlaCx-1 zG>_GiM8Fbns3V@sHwjNtAV_31MN7AT7is|Kb_<`jRy z;aiZNlL_2Xzuq`ZatPQOda@^iKhAal8yja`ZkLqj-bfg1e6@y}W}EC`WCRmUn#W>9 zNR9#?Tw|mO4`UTQ?Z^<{XW@i@U;-h?q zX_e=SOLV^22h$4{)__7nw#@TW>TRWG*nJO)myC58;MlKWO$cY>h|){7G#sVHG6`v^ zAQV35&&*D`Z5Qj~dE}UQVA+Y7PL3aN^|^GE1XWVBy>1|D*$qr39lVs1Cfvk~zy1iS z7~oPw`=W!bB+uR0ESrbId2P|$$zs*s6G|N+^>XvucYY`N*5MW^gUmNFLG1<~?%z}# zhF6xvyraxvytfVzK-Ogd?zNCC>7`2i%HZYvIBMRO}g zU!;$R%IX4S662Vd{-K6KFKU@M33>c+Fg&AzsV(Kng5ZY!BRlwSG!ucKXJj8eocwu@ zwMI#XMGo@k?g@}9K3Ewu7Kg2+#WVd3fdg=3&9R?hqN2kcQ>Ao2i$wL6i;dAVLYHIS z`k3n(<)dI18lWbSP@I0WzPUaM@;EqBZsN=WgTPwXj4djBDJ+88`&^@ThJ-bgRW8|{BiyCy?Dv^h4Z_x4A+Y9VImVBZ5aDE{6<6pBiLtn#J^AHb@Fwa~KVPp7Y+}7K& zqjyruW`;S@fB&3a@++DI&2nyDNYrsN$-;j*b%K__ zXsp$or6@mbhKem>(3YW^DAUx`)^bC~UmG(3tFV`xBstEkGr|>m1`|fu0dg-tmVs$k zS<~azkFPXCGO}!+?y0RUPtY#pQWxRj+tA|T>aNh>uM7EBdp~OQp1%#nFEH#M7(IFA zp%{ap^oq0Ifw8op#Ini)c7ivj$}a~8!4~R@S6d>f%m!i=%?F06{rK|4zhBaa)1BjI zhQPAiVdBPSO=pJf?E)=glAK=Te&zIer1zeOvZlY->q9;UR`|f8RT;rAf1{m#W6m-T zbcC-#wo5X{GPJc@$WBmE0Z5vv%0{Nv!Le&!gf^$rVAcmuU6qDz-~_GldMs>%H4}h7`6;F0H^rRd7E15ijsH#) z8SWy|!E-OxhaNmyRK>`s(aZyAHqv9ln?Z*E6|SEw5u9BHp>@gD;C*x2hH~}28*j=7 zZ?CLWADTEA7aX@b=duKuA+SWsckXHU00y>FqTF3)PVKnnxx_CV`S4jZ$u^CRO|(0=_(ZAIpRby9G^ z#i+V~xT;YO_*EP=E{x?P#p21&^O2!|KboWgeCwRu^96d5~Rxmn5 PMR_#UbXD;xFT(!^f@r$w From 5f48a54bcd20a9cf58786def615fd40853ed6347 Mon Sep 17 00:00:00 2001 From: ZhiFeng1993 Date: Mon, 29 Jun 2020 22:33:00 -0700 Subject: [PATCH 04/99] Clean up style user joutneys css file --- static/css/style_user_journeys.css | 848 ----------------------------- 1 file changed, 848 deletions(-) delete mode 100644 static/css/style_user_journeys.css diff --git a/static/css/style_user_journeys.css b/static/css/style_user_journeys.css deleted file mode 100644 index aa21c87851..0000000000 --- a/static/css/style_user_journeys.css +++ /dev/null @@ -1,848 +0,0 @@ -@font-face { - font-family: 'Material Icons'; - font-style: normal; - font-weight: 400; - src: url(iconfont/MaterialIcons-Regular.eot); /* For IE6-8 */ - src: local('Material Icons'), - local('MaterialIcons-Regular'), - url('../fonts/MaterialIcons-Regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ - url('../fonts/MaterialIcons-Regular.woff2') format('woff2'), /* Super Modern Browsers */ - url('../fonts/MaterialIcons-Regular.woff') format('woff'), /* Modern Browsers */ - url('../fonts/MaterialIcons-Regular.svg#MaterialIcons-Regular') format('svg'), /* Legacy iOS */ - url('../fonts/MaterialIcons-Regular.ttf') format('truetype'); /* Safari, Android, iOS */ -} - -.material-icons { - font-family: 'Material Icons'; - font-weight: normal; - font-style: normal; - font-size: 24px; /* Preferred icon size */ - display: inline-block; - line-height: 1; - text-transform: none; - letter-spacing: normal; - word-wrap: normal; - white-space: nowrap; - direction: ltr; - - /* Support for all WebKit browsers. */ - -webkit-font-smoothing: antialiased; - /* Support for Safari and Chrome. */ - text-rendering: optimizeLegibility; - - /* Support for Firefox. */ - -moz-osx-font-smoothing: grayscale; - - /* Support for IE. */ - font-feature-settings: 'liga'; -} - -body { - margin:0 auto; -} - -.infobarWrapper a { - color:#303030; -} - -#encyclopedia { - padding: 0px !important; -} - -span .editthispage { - display: -webkit-inline-box !important; -} - -.editthispage { - display: -webkit-inline-box !important; -} - -h1 { - padding-top: 3% !important; - padding-bottom: 1.5% !important; - padding-left: 3% !important; - padding-right: 3% !important; - text-align: center !important; - font-size: 22pt !important; - font-weight:normal; - color:#303030; -} - -.container { - width:80%; -} - -.issue-button-container { - width: 75%; - margin-left: 15%; - padding-left: 1.5%; - padding-bottom: 2%; -} - -.anchor { - display: block; - position: relative; - top: -50px; - visibility: hidden; -} - -.pages a { - font-family: 'roboto'; - font-size:11pt; - text-decoration:none !important; - letter-spacing:0.03em; - color:#606060; -} - -.pages a:hover{ - color:black; -} - -.docstitle a{ - font-family: 'roboto'; - font-size:16pt; - margin-bottom:50px !important; - color:#3371e3 !important; - text-decoration:none !important; -} - -.docstitle { - margin-bottom:10px !important; -} - -.emphasize-box { - background-color: #dde1e4; - margin: 2% 10%; - padding-top: 20px; - padding-bottom: 5px; -} - -.emphasize-box li { - font-size: 14px !important; -} - -.browsedocs { - font-family: 'roboto' !important; - width:75%; - margin-top:2%; - margin-bottom:5%; - margin-left:15%; - line-height:2em; -} - -.browsecolumn { - float:left; - width: 33%; -} - -.browsesection { - float:left; - display:block; - width:100%; - margin:2%; -} - -.pages { - width:100%; - color:#606060 !important; -} - -.browseheader { - font-family: 'roboto'; - text-align:center; - padding:1%; - color:white !important; - font-weight:100; - font-size:18px; - text-transform:uppercase; - font-weight:400; - background-color:#303030; - letter-spacing:0.08em; - background-repeat:repeat; - background-size:contain; - background-position:center; -} - -.browseheader a{ - color:white !important; -} - -.topheader { - background-color: white !important; - color:#303030; - font-family: 'roboto'; - text-align:center; - padding:3%; - font-weight:300; - font-size:24pt; - letter-spacing:0.06em; -} - -.docssectionheaders { - background-color: #eeeeee !important; - color:#3371e3; - font-family: 'roboto'; - text-align:center; - padding: 3%; - margin: 6% 0% 2% 0%; - font-weight:300; - font-size:18pt; - letter-spacing:0.06em; -} - -.docscols { - width:100%; - float:left; -} - -.section1 { - width:100%; - float:left; -} - -.docscol1 { - background-color:#eeeeee; - padding:2%; - margin-right:2%; - width:28% !important; - display:inline-block; - float:left; -} - -.docscol2 { - background-color:#ffffff; - border:1px solid #aaaaaa; - padding:2%; - width:27% !important; - float:left; - margin-right:2%; - display:inline-block; -} - -.docscol3 { - background-color:#ffffff; - padding:1.5%; - width:27% !important; - display:inline-block; - float:right; - border:1px solid blue; -} - -.docscoltitle { - float:left; - padding-top:0; - margin-right:2%; - padding-bottom:3%; - font-size:16pt; - line-height:20pt; - font-weight:400; - color:#3371e3; -} - -.docsfullcol1 { - width:95%; - padding:2%; - margin:3%; -} - -.docsfullcol2 { - width:95%; - padding:2%; - background-color:#eeeeee; - margin:3%; -} - -.docsfullcol3 { - background-color:#ffffff; - padding:2%; - width:95%; - display:inline-block; - border:1px solid blue; - margin:3%; -} - -.docsfullcol1icon { - width:5%; - padding:2%; -} - -.docstitle2 { - padding:0%; - padding-bottom:3%; - font-size:16pt; - text-align:center; - font-weight:400; - padding-top:2%; - color:#3371e3; -} - -.docsButton { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - text-decoration:none; - margin:0%; -} - -.material-icons { - font-size:50pt !important; - color:#3371e3; -} - -.paths { - padding:1%; - background-color:#3371e3; - text-align:center; -} - -.display-bar { - padding:1%; - background-color:#303030; - text-align:center; - font-size:18px; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - color:#ffffff; -} - -.cards { - padding:3%; - width:80%; - margin-left:10%; - background-color:#ffffff; - text-align:center; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; -} - -.cards > div { - display: none; -} - -button { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; -} - -.navButton { - white-space:nowrap; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:1%; - margin:1%; - color:#3371e3; - background-color:white; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - cursor: pointer; -} - -.navButton:active { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.navButton:visited { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.navButton:focus { - background-color:#3371e3 !important; - color:white; - border: 2px solid #ffffff; -} - -.navButton:hover, .keepShow { - background-color:#3371e3; - color:white; - border: 2px solid #ffffff; -} - -.buttons { - background-color:#3371e3; - white-space:nowrap; - cursor:pointer; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding: 2%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - vertical-align:middle; - line-height:1.3em; -} - -.buttonoption1 { - background-color:#3371e3; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:2%; - margin:1%; - color:#ffffff; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - width:250px; - vertical-align:middle; -} - -.buttons:active .active{ - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons:hover { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; - cursor: pointer; -} - -.buttons:target { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons:visited { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -.buttons.selected { - background-color:white; - color:#3371e3; - border: 2px solid #3371e3; -} - -/*.keepShow { - background-color:white; - color:#3371e3; - border: 2px solid white; -}*/ - -.level { - background-color:#ffffff; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #303030; - padding:0%; - padding-top:3%; - margin:1%; - margin-top:4%; - color:#303030; - font-family: 'roboto'; - font-weight:100; - text-transform:none; - text-align:center; - letter-spacing:0.1em; - display: inline-block; - width:250px; cursor: pointer; - cursor: pointer; -} - -.level:hover, .level.selected { - background-color:#dddddd; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #303030; - cursor: pointer; -} - -.tab1text{ - padding:5%; - color:#303030; - font-size:15px; - line-height:22px; -} - -.tabbottom { - background-color:#303030; - color:#ffffff;; - font-family:'roboto'; - width:100%; - margin:0px; - font-size:34 !important; -} - -i { - font-size:44px !important; - text-align:center; - color:#000066; -} - -.infobarWrapper { - visibility: hidden; - margin-bottom:5%; -} - -.infobar { - padding:0%; - background-color:#3371e3; - text-align:center; - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 2px solid #ffffff; - padding:2%; - font-size:22px; - line-height:30px; - letter-spacing:0.07em; - text-transform:uppercase; - margin:3%; - font-weight:bold; - color:#ffffff; - font-family: 'roboto'; - width:70%; - margin-left:15%; - margin-bottom:3%; -} - -.whitebar { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - background-color:#ffffff; - text-transform:none; - padding:3%; - letter-spacing:0.6pt; - font-size:15px; - z-index:99; - font-weight:400; - line-height:18pt; - color:#606060; - margin:1%; - text-align:left; -} - -.whitebararrow{ - float:right; - padding:3%; - font-size:15px; - z-index:99; - font-weight:100; - line-height:18pt; - color:#606060; - margin:1%; - text-align:right; -} - -.hide { - float:left; - font-size:16px; - padding-left:2%; - padding-bottom:5%; -} - -.fa { - line-height:0.7em !important; -} - -.infoicon { - float:left; - padding-bottom:2%; - padding-right:2%; - margin-bottom:10%; - color:#3371e3 !important; -} - -.numberCircle { - display:inline-block; - line-height:0px; - border-radius:5px; - border:2px solid; - font-weight:300; - font-size:24px; -} - -.numberCircle span { - display:inline-block; - padding-top:50%; padding-bottom:50%; - margin-left:12px; - margin-right:12px; -} - -.docButton { - -moz-border-radius: 5px; - -webkit-border-radius: 5px; - border-radius: 5px; /* future proofing */ - -khtml-border-radius: 5px; /* for old Konqueror browsers */ - border: 1.5px solid #3371e3; - padding:1%; - background-color:#eeeeee; - font-size:13px; - margin:.5%; - color:#3371e3; - font-family: 'roboto'; - text-transform:uppercase; - text-align:center; - letter-spacing:0.1em; - display: inline-block; -} - -.docButton:hover { - border: 1.5px solid #3371e3; - background-color:#3371e3; - font-size:13px; - color:#eeeeee; -} - -.tablebar { - text-align:center; - background-color:#eeeeee; - padding:1.5%; -} - -.aboutsection { - background-color:white; - font-family: 'roboto'; - font-weight:300 !important; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:70%; - margin-left:15%; - padding-bottom:5%; -} - -.aboutsection p { - font-size: 16px; - text-align:center; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; - margin-bottom: 0.75em; -} - -.aboutsection a { - text-decoration: underline; - color:#3371e3; - font-weight:400; -} - -.aboutcolumn { - float:left; - width: 50%; - text-align: center; -} - -.docsection1 { - background-color:white; - font-family: 'roboto'; - font-weight:300 !important; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:65%; - margin-left:17%; - margin-top : 10%; - padding:4%; -} - -#persona-definition { - visibility: hidden; -} - -.about-k8s-content { - width: 100%; - float: right; -} - -.docsection1 a { - text-decoration: underline; -} - -.docsection1 p { - font-size: 16px; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; - margin-bottom: 0.75em; -} - -.docsection1 li { - margin-bottom: 0.75em; - margin-left: 3em; - font-size: 16px; - font-weight:300; - line-height: 1.75em; - letter-spacing: 0.1px; -} - -.docsection1 ol li { - list-style: decimal; -} - -.docsection1 ul li { - list-style: disc; -} - -.docsection1 code { - font-family: Menlo, Monaco, Consolas, 'Courier New', monospace; - font-size: 90%; - padding: 2px 4px; - color: #c7254e; - border-radius: 4px; - background-color: #f9f2f4; -} - -.intro { - background-color:white; - font-family: 'roboto'; - padding:3%; - font-weight:100; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:100%; - margin-left:10%; -} - -.introtext { - float:right; - background-color:white; - font-family: 'roboto'; - padding:3%; - font-weight:100; - font-size:14px; - letter-spacing:0.05em; - line-height:22px; - width:50%; - margin-left:10%; -} - -.track { - background-color:#3371e3; - font-family: 'roboto'; - padding:1%; - color:white; - font-weight:500; - text-align:center; - text-transform:uppercase; - font-size:16px; - letter-spacing:0.05em; - line-height:22px; - width:100%; -} - -.sections { - background-color:#303030; - font-family: 'roboto'; - padding:1%; - color:white; - font-weight:500; - text-align:center; - text-transform:uppercase; - font-size:18px; - letter-spacing:0.05em; - line-height:22px; - width:100%; -} - -.quotedocs { - line-height:26pt; - font-size:16pt; -} - -table { - width: 100%; - border: 1px solid #ccc; - border-spacing: 0; - margin-top: 30px; - margin-bottom: 30px; -} - -thead, tr:nth-child(even) { - background-color: light-grey; -} - -thead { - background-color: #555; - color: white; -} - -th, td { - padding: 8px; - text-align: left; - margin: 0; - border: 1px solid #ccc; -} - -th { - font-weight: normal; -} - -@media screen and (max-width: 640px) { - - .browsecolumn { - width: 95%; - } - - .paths { - margin-top : 10%; - padding:4%; - } - - .navButton { - padding:2%; - } - - .buttons { - padding:4%; - } - - .whitebar { - padding:5%; - } -} - From 9626db512167b437b75885b020755961088a79b7 Mon Sep 17 00:00:00 2001 From: Arhell Date: Thu, 2 Jul 2020 00:55:50 +0300 Subject: [PATCH 05/99] fix table content --- assets/scss/_custom.scss | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index f02d6d908b..d040211f79 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -264,6 +264,14 @@ footer { } } +main { + .td-content table code, + .td-content>table td { + word-break: break-word; + } +} + + // blockquotes and callouts blockquote { From 4ddc1663f2181511a2eb2575b41c3a7c3acf7dc7 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Thu, 2 Jul 2020 16:30:52 +0800 Subject: [PATCH 06/99] Add a kubectl tip for working with keys with dots --- content/en/docs/reference/kubectl/cheatsheet.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 36629d2c29..dda75574a9 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -166,6 +166,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# Retrieve the value of a key with dots, e.g. 'ca.crt' +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # Get all worker nodes (use a selector to exclude results that have a label # named 'node-role.kubernetes.io/master') kubectl get node --selector='!node-role.kubernetes.io/master' From f34fe97ba0da469cb3fb521369a3811578d2e0cf Mon Sep 17 00:00:00 2001 From: Jorge Gallegos Date: Thu, 2 Jul 2020 12:12:15 -0500 Subject: [PATCH 07/99] Removing duplicate custom-jekyll js After docsy theme got merged these scripts aren't needed anymore. Confirmed after removing it (and all ` - {{ with .Params.js }}{{ range (split . ",") }} {{ end }}{{ else }}{{ end }} \ No newline at end of file diff --git a/static/js/custom-jekyll/tags.js b/static/js/custom-jekyll/tags.js deleted file mode 100644 index d99660ee60..0000000000 --- a/static/js/custom-jekyll/tags.js +++ /dev/null @@ -1,15 +0,0 @@ -$( document ).ready(function() { - // Shows permalink when term name is hovered over - $(".glossary-injector").each(function() { - var placeholder = $("#" + $(this).data("placeholder-id")); - var originalContent = placeholder.html(); - - var glossaryDef = $($(this).find(".injector-def")[0]).html(); - - $(this).mouseenter(function() { - placeholder.html(glossaryDef); - }).mouseleave(function(){ - placeholder.html(originalContent); - }); - }); -}); From 25e76c02737957fe9c415dcaa76f1faeaeedaf26 Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Thu, 2 Jul 2020 10:39:21 -0700 Subject: [PATCH 08/99] Add page for PR wranglers --- content/en/docs/contribute/advanced.md | 65 +---------------- .../contribute/participate/pr-wranglers.md | 69 +++++++++++++++++++ .../participate/roles-and-responsibilties.md | 10 ++- 3 files changed, 78 insertions(+), 66 deletions(-) create mode 100644 content/en/docs/contribute/participate/pr-wranglers.md diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 594816a2b5..44c72916d9 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -17,67 +17,6 @@ client and other tools for some of these tasks. -## Be the PR Wrangler for a week - -SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. - -The PR wrangler’s duties include: - -- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. - - Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`). - - Review as many PRs as you can. -- Ensure that the CLA is signed by each contributor. - - Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA. -- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs. - - Provide inline suggestions on the PR for the proposed content changes. - - If you need to verify content, comment on the PR and request more details. - - Assign relevant `sig/` label(s). - - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - - Assign `/lgtm` and `/approve` labels to PRs that can be merged. -- Merge PRs when they are ready, or close PRs that shouldn’t be accepted. - - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. -- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. - -### Helpful GitHub queries for wranglers - -The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to be -reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one). - -- [No CLA, not eligible to 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): - Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close - the PR and remind them that they can open it after signing the CLA. - **Do not review PRs whose authors have not signed the CLA!** -- [Needs 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+): - If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review - or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along. -- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`. -- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): If it’s a small PR against master with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). -- [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): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch. - -### When to close Pull Requests - -Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. - -- Close any PR where the CLA hasn’t been signed for two weeks. -PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA. - -- Close any PR where the author has not responded to comments or feedback in 2 or more weeks. - -Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution. - -To close a pull request, leave a `/close` comment on the PR. - -{{< note >}} - -An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity. - -{{< /note >}} - ## Propose improvements SIG Docs [members](/docs/contribute/participating/#members) can propose improvements. @@ -244,6 +183,4 @@ When you’re ready to start the recording, click Record to Cloud. When you’re ready to stop recording, click Stop. -The video uploads automatically to YouTube. - - +The video uploads automatically to YouTube. \ No newline at end of file diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md new file mode 100644 index 0000000000..6538e813df --- /dev/null +++ b/content/en/docs/contribute/participate/pr-wranglers.md @@ -0,0 +1,69 @@ +--- +title: PR wranglers +content_type: concept +weight: 20 +--- + + + +SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. + +This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). + + + +## Duties + +Each day in a week-long shift as PR Wrangler: + +- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. +- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. + - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can. +- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so. +- Provide feedback on changes and ask for technical reviews from members of other SIGs. + - Provide inline suggestions on the PR for the proposed content changes. + - If you need to verify content, comment on the PR and request more details. + - Assign relevant `sig/` label(s). + - If needed, assign reviewers from the `reviewers:` block in the file's front matter. +- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready. + - PRs should have a `/lgtm` comment from another member before merging. + - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. + +### Helpful GitHub queries for wranglers + +The following queries are helpful when wrangling. +After working through these queries, the remaining list of PRs to review is usually small. +These queries exclude localization PRs. All queries are against the main branch except the last one. + +- [No CLA, not eligible to 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): + Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close + the PR and remind them that they can open it after signing the CLA. + **Do not review PRs whose authors have not signed the CLA!** +- [Needs 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+): + Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line. +- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): + Lists PRs that need an `/approve` comment to merge. +- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). +- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch. + +### When to close Pull Requests + +Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. + +Close PRs where: +- The author hasn't signed the CLA for two weeks. + + Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA. + +- The author has not responded to comments or feedback in 2 or more weeks. + +Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution. + +To close a pull request, leave a `/close` comment on the PR. + +{{< note >}} + +The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity. + +{{< /note >}} \ No newline at end of file diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md index b01beec352..179acf0009 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilties.md @@ -171,7 +171,7 @@ Approvers and SIG Docs leads are the only ones who can merge pull requests into - Visit the Netlify page preview for a PR to make sure things look good before approving. - Participate in the [PR Wrangler rotation schedule](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) +rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers) for more details. ### Becoming an approver @@ -188,4 +188,10 @@ To apply: 2. Assign the PR to one or more current SIG Docs approvers. -If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. \ No newline at end of file +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. + +## {{% heading "whatsnext" %}} + +Learn about specialized roles in SIG Docs: + +- [PR wranglers](/docs/contribute/participating/pr-wranglers) \ No newline at end of file From 9aad658f6a7db56e6b1c9ae20777b104f07bc785 Mon Sep 17 00:00:00 2001 From: Saba Zubair Date: Fri, 3 Jul 2020 21:12:27 -0400 Subject: [PATCH 09/99] =?UTF-8?q?removed=20anchor-4.1.1-min.js=20file=20fr?= =?UTF-8?q?om=20static/js/anchor-4.1.1=20and=20the=20corresponding=20call?= =?UTF-8?q?=20in=20/layouts/partial/head.html#L77.=20This=20completes=20#2?= =?UTF-8?q?2040=20and=20serves=20as=20my=20first=20contribution=20to=20an?= =?UTF-8?q?=20OS=20project.=20=F0=9F=8E=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- layouts/partials/head.html | 1 - static/js/anchor-4.1.1.min.js | 6 ------ 2 files changed, 7 deletions(-) delete mode 100644 static/js/anchor-4.1.1.min.js diff --git a/layouts/partials/head.html b/layouts/partials/head.html index 43d1a91c67..d0a2eb064f 100644 --- a/layouts/partials/head.html +++ b/layouts/partials/head.html @@ -74,7 +74,6 @@ {{ end }} - diff --git a/static/js/anchor-4.1.1.min.js b/static/js/anchor-4.1.1.min.js deleted file mode 100644 index 29a64acae6..0000000000 --- a/static/js/anchor-4.1.1.min.js +++ /dev/null @@ -1,6 +0,0 @@ -/** - * AnchorJS - v4.1.1 - 2018-07-01 - * https://github.com/bryanbraun/anchorjs - * Copyright (c) 2018 Bryan Braun; Licensed MIT - */ -!function(A,e){"use strict";"function"==typeof define&&define.amd?define([],e):"object"==typeof module&&module.exports?module.exports=e():(A.AnchorJS=e(),A.anchors=new A.AnchorJS)}(this,function(){"use strict";return function(A){function d(A){A.icon=A.hasOwnProperty("icon")?A.icon:"",A.visible=A.hasOwnProperty("visible")?A.visible:"hover",A.placement=A.hasOwnProperty("placement")?A.placement:"right",A.ariaLabel=A.hasOwnProperty("ariaLabel")?A.ariaLabel:"Anchor",A.class=A.hasOwnProperty("class")?A.class:"",A.truncate=A.hasOwnProperty("truncate")?Math.floor(A.truncate):64}function f(A){var e;if("string"==typeof A||A instanceof String)e=[].slice.call(document.querySelectorAll(A));else{if(!(Array.isArray(A)||A instanceof NodeList))throw new Error("The selector provided to AnchorJS was invalid.");e=[].slice.call(A)}return e}this.options=A||{},this.elements=[],d(this.options),this.isTouchDevice=function(){return!!("ontouchstart"in window||window.DocumentTouch&&document instanceof DocumentTouch)},this.add=function(A){var e,t,i,n,o,s,r,a,c,h,l,u=[];if(d(this.options),"touch"===(l=this.options.visible)&&(l=this.isTouchDevice()?"always":"hover"),A||(A="h2, h3, h4, h5, h6"),0===(e=f(A)).length)return this;for(function(){if(null===document.head.querySelector("style.anchorjs")){var A,e=document.createElement("style");e.className="anchorjs",e.appendChild(document.createTextNode("")),void 0===(A=document.head.querySelector('[rel="stylesheet"], style'))?document.head.appendChild(e):document.head.insertBefore(e,A),e.sheet.insertRule(" .anchorjs-link { opacity: 0; text-decoration: none; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; }",e.sheet.cssRules.length),e.sheet.insertRule(" *:hover > .anchorjs-link, .anchorjs-link:focus { opacity: 1; }",e.sheet.cssRules.length),e.sheet.insertRule(" [data-anchorjs-icon]::after { content: attr(data-anchorjs-icon); }",e.sheet.cssRules.length),e.sheet.insertRule(' @font-face { font-family: "anchorjs-icons"; src: url(data:n/a;base64,AAEAAAALAIAAAwAwT1MvMg8yG2cAAAE4AAAAYGNtYXDp3gC3AAABpAAAAExnYXNwAAAAEAAAA9wAAAAIZ2x5ZlQCcfwAAAH4AAABCGhlYWQHFvHyAAAAvAAAADZoaGVhBnACFwAAAPQAAAAkaG10eASAADEAAAGYAAAADGxvY2EACACEAAAB8AAAAAhtYXhwAAYAVwAAARgAAAAgbmFtZQGOH9cAAAMAAAAAunBvc3QAAwAAAAADvAAAACAAAQAAAAEAAHzE2p9fDzz1AAkEAAAAAADRecUWAAAAANQA6R8AAAAAAoACwAAAAAgAAgAAAAAAAAABAAADwP/AAAACgAAA/9MCrQABAAAAAAAAAAAAAAAAAAAAAwABAAAAAwBVAAIAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAMCQAGQAAUAAAKZAswAAACPApkCzAAAAesAMwEJAAAAAAAAAAAAAAAAAAAAARAAAAAAAAAAAAAAAAAAAAAAQAAg//0DwP/AAEADwABAAAAAAQAAAAAAAAAAAAAAIAAAAAAAAAIAAAACgAAxAAAAAwAAAAMAAAAcAAEAAwAAABwAAwABAAAAHAAEADAAAAAIAAgAAgAAACDpy//9//8AAAAg6cv//f///+EWNwADAAEAAAAAAAAAAAAAAAAACACEAAEAAAAAAAAAAAAAAAAxAAACAAQARAKAAsAAKwBUAAABIiYnJjQ3NzY2MzIWFxYUBwcGIicmNDc3NjQnJiYjIgYHBwYUFxYUBwYGIwciJicmNDc3NjIXFhQHBwYUFxYWMzI2Nzc2NCcmNDc2MhcWFAcHBgYjARQGDAUtLXoWOR8fORYtLTgKGwoKCjgaGg0gEhIgDXoaGgkJBQwHdR85Fi0tOAobCgoKOBoaDSASEiANehoaCQkKGwotLXoWOR8BMwUFLYEuehYXFxYugC44CQkKGwo4GkoaDQ0NDXoaShoKGwoFBe8XFi6ALjgJCQobCjgaShoNDQ0NehpKGgobCgoKLYEuehYXAAAADACWAAEAAAAAAAEACAAAAAEAAAAAAAIAAwAIAAEAAAAAAAMACAAAAAEAAAAAAAQACAAAAAEAAAAAAAUAAQALAAEAAAAAAAYACAAAAAMAAQQJAAEAEAAMAAMAAQQJAAIABgAcAAMAAQQJAAMAEAAMAAMAAQQJAAQAEAAMAAMAAQQJAAUAAgAiAAMAAQQJAAYAEAAMYW5jaG9yanM0MDBAAGEAbgBjAGgAbwByAGoAcwA0ADAAMABAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAH//wAP) format("truetype"); }',e.sheet.cssRules.length)}}(),t=document.querySelectorAll("[id]"),i=[].map.call(t,function(A){return A.id}),o=0;o\]\.\/\(\)\*\\\n\t\b\v]/g,"-").replace(/-{2,}/g,"-").substring(0,this.options.truncate).replace(/^-+|-+$/gm,"").toLowerCase()},this.hasAnchorJSLink=function(A){var e=A.firstChild&&-1<(" "+A.firstChild.className+" ").indexOf(" anchorjs-link "),t=A.lastChild&&-1<(" "+A.lastChild.className+" ").indexOf(" anchorjs-link ");return e||t||!1}}}); \ No newline at end of file From cf1cc32b84d8c8b1eec3f1ad5703c5a5f0a3d682 Mon Sep 17 00:00:00 2001 From: Arhell Date: Sat, 4 Jul 2020 12:35:28 +0300 Subject: [PATCH 10/99] fix heading text --- assets/scss/_custom.scss | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index f02d6d908b..98a0b7ddff 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -118,7 +118,7 @@ section { } @media only screen and (min-width: 1075px) { - margin-top: 1.5rem !important; + margin-top: 1rem !important; } } From 393c40c680e5e63e8cbbc83c107e89c4fd98bf2d Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 30 May 2020 14:27:39 +0800 Subject: [PATCH 11/99] [zh] Synchronize the README file --- README-zh.md | 256 +++++++++++++++++++++++---------------------------- 1 file changed, 117 insertions(+), 139 deletions(-) diff --git a/README-zh.md b/README-zh.md index 8a7898774a..5b4353127f 100644 --- a/README-zh.md +++ b/README-zh.md @@ -1,74 +1,139 @@ # Kubernetes 文档 + +--> -[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) -[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -欢迎！本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/)的内容。 +This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! +--> +本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/) 的软件资产。 我们非常高兴您想要参与贡献！ + +## 在本地使用 Hugo 来运行网站 + +请参考 [Hugo 的官方文档](https://gohugo.io/getting-started/installing/)了解 Hugo 的安装指令。 +请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的 +Hugo 扩展版本。 + + +在构造网站之前，先克隆 Kubernetes website 仓库： + +```bash +git clone https://github.com/kubernetes/website.git +cd website +git submodule update --init --recursive +``` + + +**注意：** Kubernetes 网站要部署 [Docsy Hugo 主题](https://github.com/google/docsy#readme). +如果你还没有更新你本地的 website 仓库，目录 `website/themes/docsy` +会是空目录。 +在本地没有主题副本的情况下，网站无法正常构造。 + +使用下面的命令更新网站主题： + +```bash +git submodule update --init --recursive --depth 1 +``` + + +若要在本地构造和测试网站，请运行： + +```bash +hugo server --buildFuture +``` + + +上述命令会在端口 1313 上启动本地 Hugo 服务器。 +启动浏览器，打开 http://localhost:1313 来查看网站。 +当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。 + + +## 参与 SIG Docs 工作 + +通过 [社区页面](https://github.com/kubernetes/community/tree/master/sig-docs#meetings) +进一步了解 SIG Docs Kubernetes 社区和会议信息。 + +你也可以通过以下渠道联系本项目的维护人员： + +- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + -## 贡献文档 + +You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. + +Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** +--> +## 为文档做贡献 + +你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub +账号下创建本仓库的拷贝。此拷贝被称作 *fork*。 +你可以在自己的拷贝中任意地修改文档，并在你已准备好将所作修改提交给我们时， +在你自己的拷贝下创建一个拉取请求（Pull Request），以便让我们知道。 + +一旦你创建了拉取请求，某个 Kubernetes 评审人会负责提供明确的、可执行的反馈意见。 +作为拉取请求的拥有者，*修改拉取请求以解决 Kubernetes +评审人所提出的反馈是你的责任*。 -您可以点击屏幕右上方的 **Fork** 按钮，在您的 GitHub 账户下创建一份本仓库的副本。这个副本叫做 *fork*。您可以对 fork 副本进行任意修改， -当准备好把修改提交给我们时，您可以通过创建一个 pull request 来告知我们。 - - -创建 pull request 后，Kubernetes 审核人员将负责提供清晰且可操作的反馈。作为 pull request 的所有者，**您有责任修改 pull request 以解决 Kubernetes 审核者提供给您的反馈。** -另请注意，您最终可能会收到多个 Kubernetes 审核人员为您提供的反馈，也可能出现后面 Kubernetes 审核人员的反馈与前面审核人员的反馈不尽相同的情况。 -此外，在某些情况下，您的某位评审员可能会在需要时要求 [Kubernetes 技术评审员](https://github.com/kubernetes/website/wiki/Tech-reviewers) 进行技术评审。 -审稿人将尽最大努力及时提供反馈，但响应时间可能因情况而异。 + +Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances. +--> +还要提醒的一点，有时可能会有不止一个 Kubernetes 评审人为你提供反馈意见。 +有时候，某个评审人的意见和另一个最初被指派的评审人的意见不同。 + +更进一步，在某些时候，评审人之一可能会在需要的时候请求 Kubernetes +技术评审人来执行技术评审。 +评审人会尽力及时地提供反馈意见，不过具体的响应时间可能会因时而异。 +--> 有关为 Kubernetes 文档做出贡献的更多信息，请参阅： -* [开始贡献](https://kubernetes.io/docs/contribute/start/) -* [缓存您的文档变更](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [使用页面模版](http://kubernetes.io/docs/contribute/style/page-templates/) +* [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/) +* [页面内容类型](http://kubernetes.io/docs/contribute/style/page-content-types/) * [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/) * [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/) - -## `README.md` 的本地化 Kubernetes 文档 - - -### 中文 +## 中文本地化 可以通过以下方式联系中文本地化的维护人员： @@ -76,107 +141,20 @@ You can reach the maintainers of Korean localization at: * He Xiaolong ([GitHub - @markthink](https://github.com/markthink)) * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh) - -## 在本地使用 docker 运行网站 - - -在本地运行 Kubernetes 网站的推荐方法是运行包含 [Hugo](https://gohugo.io) 静态网站生成器的专用 [Docker](https://docker.com) 镜像。 - - -> 如果您使用的是 Windows，则需要一些工具，可以使用 [Chocolatey](https://chocolatey.org) 进行安装。`choco install make` - - -> 如果您更喜欢在没有 Docker 的情况下在本地运行网站，请参阅下面的[使用 Hugo 在本地运行网站](#running-the-site-locally-using-hugo) 章节。 - - -如果您已经[安装运行](https://www.docker.com/get-started)了 Docker，使用以下命令在本地构建 `kubernetes-hugo` Docker 镜像： - -```bash -make docker-image -``` - - -一旦创建了镜像，您就可以在本地运行网站了： - -```bash -make docker-serve -``` - - -打开浏览器访问 http://localhost:1313 以查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。 - - -## 使用 Hugo 在本地运行网站 {#running-the-site-locally-using-hugo} - - -有关 Hugo 的安装说明，请参阅 [Hugo 官方文档](https://gohugo.io/getting-started/installing/)。 -确保安装对应版本的 Hugo，版本号由 [`netlify.toml`](netlify.toml#L9) 文件中的 `HUGO_VERSION` 环境变量指定。 - - -安装 Hugo 后，在本地运行网站： - -```bash -make serve -``` - - -这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。 - - -## 社区、讨论、贡献和支持 - - -在[社区页面](http://kubernetes.io/community/)了解如何与 Kubernetes 社区互动。 - - -您可以通过以下方式联系该项目的维护人员： - -- [Slack](https://kubernetes.slack.com/messages/sig-docs) -- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - +Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +--> ### 行为准则 -参与 Kubernetes 社区受 [Kubernetes 行为准则](code-of-conduct.md)的约束。 +参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)约束。 +--> ## 感谢！ Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！ From 423f391c68100fe0576fd105fa487b566a0c870e Mon Sep 17 00:00:00 2001 From: wxsm Date: Mon, 6 Jul 2020 13:06:09 +0800 Subject: [PATCH 12/99] fix zh doc misleading to en link. fix zh doc misleading to en link. --- .../tutorials/kubernetes-basics/update/update-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html index 6f52711e17..0f9ea050c3 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -32,7 +32,7 @@ weight: 20
- 回到 Kubernetes 的基础› + 回到 Kubernetes 的基础›
From 906517f3ffa708329051fab343bac44610777995 Mon Sep 17 00:00:00 2001 From: Ross Wilson Date: Mon, 6 Jul 2020 17:47:52 +0200 Subject: [PATCH 13/99] Fix erroneous RSS feed link in security.md When referring to the `kubernetes-security-announce` mailing list, an alternative RSS link is incorrectly given to `kubernetes-announce` instead. This PR updates that link. --- content/en/docs/reference/issues-security/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index b9b1ce7c37..2d16e37662 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -19,7 +19,7 @@ This page describes Kubernetes security and disclosure information. Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements. -You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50). +You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50). ## Report a Vulnerability From a6a41daee939f01b1482cdd65e985806a0d08272 Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Mon, 6 Jul 2020 11:54:22 -0700 Subject: [PATCH 14/99] Apply suggestions from code review Co-authored-by: Tim Bannister --- .../contribute/participate/roles-and-responsibilties.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md index 179acf0009..346ce0321f 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilties.md @@ -171,7 +171,7 @@ Approvers and SIG Docs leads are the only ones who can merge pull requests into - Visit the Netlify page preview for a PR to make sure things look good before approving. - Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers) +rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/). for more details. ### Becoming an approver @@ -188,10 +188,10 @@ To apply: 2. Assign the PR to one or more current SIG Docs approvers. -If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. ## {{% heading "whatsnext" %}} Learn about specialized roles in SIG Docs: -- [PR wranglers](/docs/contribute/participating/pr-wranglers) \ No newline at end of file +- [PR wranglers](/docs/contribute/participating/pr-wranglers) From 52f2920d5f7fcef706ab0d9130c3dcbe04843fa7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Raymond=20Maug=C3=A9?= Date: Mon, 6 Jul 2020 18:03:45 -0400 Subject: [PATCH 15/99] Updates minor spelling correction "can not" to "cannot" --- .../docs/concepts/overview/working-with-objects/namespaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 07e7dac726..59b1763450 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -26,7 +26,7 @@ need to create or think about namespaces at all. Start using namespaces when yo need the features they provide. Namespaces provide a scope for names. Names of resources need to be unique within a namespace, -but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes +but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes resource can only be in one namespace. Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)). From b05f9569c7c0e69a5adda09dcc8de822be19bea6 Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Mon, 6 Jul 2020 15:56:46 -0700 Subject: [PATCH 16/99] Address feedback --- .../docs/contribute/participate/roles-and-responsibilties.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md index 346ce0321f..7536464ce0 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilties.md @@ -192,6 +192,4 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added ## {{% heading "whatsnext" %}} -Learn about specialized roles in SIG Docs: - -- [PR wranglers](/docs/contribute/participating/pr-wranglers) +- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation. \ No newline at end of file From e8aa06428937113429a9fd206c72d0a73121a087 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 23 Jun 2020 10:46:27 +0800 Subject: [PATCH 17/99] [zh] Sync contribution guidelines (2) This PR is about the changes to reference generation. --- .../contribute/generate-ref-docs/_index.md | 17 +- .../generate-ref-docs/contribute-upstream.md | 221 +++++----- .../contribute/generate-ref-docs/kubectl.md | 319 ++++++-------- .../generate-ref-docs/kubernetes-api.md | 307 ++++++------- .../kubernetes-components.md | 403 +---------------- .../prerequisites-ref-docs.md | 45 ++ .../generate-ref-docs/quickstart.md | 405 ++++++++++++++++++ 7 files changed, 845 insertions(+), 872 deletions(-) create mode 100644 content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md create mode 100644 content/zh/docs/contribute/generate-ref-docs/quickstart.md diff --git a/content/zh/docs/contribute/generate-ref-docs/_index.md b/content/zh/docs/contribute/generate-ref-docs/_index.md index ac5f61a40f..7afd3743f5 100644 --- a/content/zh/docs/contribute/generate-ref-docs/_index.md +++ b/content/zh/docs/contribute/generate-ref-docs/_index.md @@ -5,17 +5,22 @@ weight: 80 --- -许多 Kubernetes 参考文档都是使用脚本从 Kubernetes 源代码生成的。本节的主题是如何生成这种类型的文档。 +本节的主题是描述如何生成 Kubernetes 参考指南。 +要生成参考文档，请参考下面的指南： + +* [生成参考文档快速入门](/docs/contribute/generate-ref-docs/quickstart/) + diff --git a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md index f71871b296..4bfa40f0a8 100644 --- a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -1,12 +1,12 @@ --- title: 为上游 Kubernetes 代码库做出贡献 content_type: task +weight: 20 --- @@ -16,93 +16,83 @@ 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. --> -此页面描述如何为上游 kubernetes/kubernetes 项目做出贡献，如修复 Kubernetes API 文档或 `kube-*` 组件（例如 kube-apiserver、kube-controller-manager 等）中发现的错误。 +此页面描述如何为上游 `kubernetes/kubernetes` 项目做出贡献，如修复 Kubernetes API +文档或 Kubernetes 组件（例如 `kubeadm`、`kube-apiserver`、`kube-controller-manager` 等） +中发现的错误。 -相反，如果您想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： - +如果您仅想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： + - [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/) - [生成 Kubernetes 组件和工具的参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/) - - - ## {{% heading "prerequisites" %}} - -您需要安装以下工具： +- 你需要安装以下工具： + + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) 的 1.13 版本或更高 + - [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) Go 版本大于 1.9.1 -* [Docker](https://docs.docker.com/engine/installation/) -* [etcd](https://github.com/coreos/etcd/) +- 你必须设置 `GOPATH` 环境变量，并且 `etcd` 的位置必须在 `PATH` 环境变量中。 -必须设置 $GOPATH 环境变量，并且 `etcd` 的位置必须在 $PATH 环境变量中。 - - -您需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。 -通常，这涉及创建代码仓库的分支。要获取更多的信息请参考[创建 PR](https://help.github.com/articles/creating-a-pull-request/) 和 -[GitHub 标准 Fork 和 PR 工作流程](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - - +- 您需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。 + 通常，这涉及创建代码仓库的派生副本。 + 要获取更多的信息请参考[创建 PR](https://help.github.com/articles/creating-a-pull-request/) 和 + [GitHub 标准派生和 PR 工作流程](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 -## 基本原则 - -Kubernetes API 和 `kube-*` 组件（例如 `kube-apiserver`、`kube-controller-manager`）的参考文档是根据[上游 Kubernetes](https://github.com/kubernetes/kubernetes/) 中的源代码自动生成的。 - +## 基本说明 + +Kubernetes API 和 `kube-*` 组件（例如 `kube-apiserver`、`kube-controller-manager`）的参考文档 +是根据[上游 Kubernetes](https://github.com/kubernetes/kubernetes/) 中的源代码自动生成的。 + 当您在生成的文档中看到错误时，您可能需要考虑创建一个 PR 用来在上游项目中对其进行修复。 ## 克隆 Kubernetes 代码仓库 - -如果您还没有 kubernetes/kubernetes 代码仓库，请立即参照下列命令获取： +如果您还没有 kubernetes/kubernetes 代码仓库，请参照下列命令获取： ```shell mkdir $GOPATH/src @@ -117,9 +107,10 @@ For example, if you followed the preceding step to get the repository, your base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.` The remaining steps refer to your base directory as ``. --> -确定您的 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库克隆的基本目录。 -例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes/kubernetes`。 -接下来其余步骤将您的基本目录称为 ``。 +确定您的 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库克隆的根目录。 +例如，如果按照前面的步骤获取代码仓库，则你的根目录为 `$GOPATH/src/github.com/kubernetes/kubernetes`。 +接下来其余步骤将你的根目录称为 ``。 + -确定您的 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 代码仓库克隆的基本目录。 -例如，如果按照前面的步骤获取代码仓库，则您的基本目录为 `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 -接下来其余步骤将您的基本目录称为 ``。 +确定您的 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) +代码仓库克隆的根目录。 +例如，如果按照前面的步骤获取代码仓库，则你的根目录为 +`$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 +接下来其余步骤将你的根目录称为 ``。 -## 编辑 Kubernetes 源代码 - -Kubernetes API 参考文档是根据 OpenAPI 规范自动生成的，该规范是从 Kubernetes 源代码生成的。如果要更改 API 参考文档，第一步是更改 Kubernetes 源代码中的一个或多个注释。 +## 编辑 Kubernetes 源代码 + +Kubernetes API 参考文档是根据 OpenAPI 规范自动生成的，该规范是从 Kubernetes 源代码生成的。 +如果要更改 API 参考文档，第一步是更改 Kubernetes 源代码中的一个或多个注释。 -### 更改上游 Kubernetes 源代码 - +### 更改上游 Kubernetes 源代码 + {{< note >}} -以下步骤仅作为示例，不是一般步骤，具体情况因您而异。 +以下步骤仅作为示例，不是通用步骤，具体情况因环境而异。 {{< /note >}} -以下在 Kubernetes 源代码中编辑注释的示例。 - -在您本地的 kubernetes/kubernetes 代码仓库中，切换出本地 master 分支，并确保它是最新的： +以下在 Kubernetes 源代码中编辑注释的示例。 + +在您本地的 kubernetes/kubernetes 代码仓库中，检出 master 分支，并确保它是最新的： ```shell cd @@ -184,19 +175,18 @@ git pull https://github.com/kubernetes/kubernetes master -假设 master 分支中的此源文件的拼写错误为 "atmost"： +假设 master 分支中的下面源文件中包含拼写错误 "atmost"： [kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go) -在您的本地环境中，打开 `types.go` 文件，然后将 "atmost" 更改为 "at most"。 - -以下命令查看您已更改的文件： +在你的本地环境中，打开 `types.go` 文件，然后将 "atmost" 更改为 "at most"。 + +以下命令验证你已经更改了文件： ```shell git status @@ -216,23 +206,22 @@ On branch master -### 提交已编辑的文件 - -运行 `git add` 和 `git commit` 命令提交到目前为止所做的更改。在下一步中，您将进行第二次提交，将更改分成两个提交很重要。 +### 提交已编辑的文件 + +运行 `git add` 和 `git commit` 命令提交到目前为止所做的更改。 +在下一步中，您将进行第二次提交，将更改分成两个提交很重要。 ### 生成 OpenAPI 规范和相关文件 - 进入 `` 目录并运行以下脚本： ```shell @@ -242,12 +231,10 @@ hack/update-generated-protobuf.sh hack/update-api-reference-docs.sh ``` - -运行 `git status` 命令查看生成的东西。 + +运行 `git status` 命令查看生成的文件。 -```shell +```none On branch master ... modified: api/openapi-spec/swagger.json @@ -264,14 +251,16 @@ For example, you could run `git diff -a api/openapi-spec/swagger.json`. This is important, because `swagger.json` is the input to the second stage of the doc generation process. --> -查看 `api/openapi-spec/swagger.json` 的内容，以确保 typo 已经被修正。例如，您可以运行 `git diff -a api/openapi-spec/swagger.json` 命令。这很重要，因为 `swagger.json` 是文档生成过程中第二阶段的输入。 +查看 `api/openapi-spec/swagger.json` 的内容，以确保拼写错误已经被修正。 +例如，您可以运行 `git diff -a api/openapi-spec/swagger.json` 命令。 +这很重要，因为 `swagger.json` 是文档生成过程中第二阶段的输入。 -运行 `git add` 和 `git commit` 命令来提交您的更改。现在您有两个提交： +运行 `git add` 和 `git commit` 命令来提交您的更改。现在您有两个提交（commits）： 一种包含编辑的 `types.go` 文件，另一种包含生成的 OpenAPI 规范和相关文件。 将这两个提交分开独立。也就是说，不要 squash 您的提交。 @@ -283,13 +272,16 @@ master branch of the Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it is merged. --> -将您的更改作为 [PR](https://help.github.com/articles/creating-a-pull-request/) 提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库的 master 分支。关注您的 PR，并根据需要回复 reviewer 的评论。继续关注您的 PR，直到 PR 被合并为止。 +将您的更改作为 [PR](https://help.github.com/articles/creating-a-pull-request/) +提交到 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 代码仓库的 master 分支。 +关注您的 PR，并根据需要回复 reviewer 的评论。继续关注您的 PR，直到 PR 被合并为止。 -[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是修复 Kubernetes 源代码中的拼写错误的拉取请求的示例。 +[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) 是修复 Kubernetes +源代码中的拼写错误的拉取请求的示例。 {{< note >}} -确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 `kubernetes/kubernetes` 代码仓库的 `staging` 目录中。但是根据您的情况，`staging` 目录可能不是找到官方源文件的地方。根据指导原则，请检查 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) 代码仓库和相关代码仓库（例如 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)）中的 `README` 文件。 +确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 `kubernetes/kubernetes` +代码仓库的 `staging` 目录中。但是根据您的情况，`staging` 目录可能不是找到官方源文件的地方。 +如果需要帮助，请阅读 +[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) +代码仓库和相关代码仓库 +（例如 [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md)） +中的 `README` 文件。 {{< /note >}} -### Cherry Pick 将您的提交纳入发布分支 - -在上一节中，您在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。然后将您的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支的 pull request 中。 现在，需要将您的更改反向移植到已经 release 的分支。例如，假设使用 master 分支来开发 Kubernetes 1.10 版，并且您想将更改反向移植到 release-1.9 分支。 +### 将你的提交 Cherrypick 到发布分支 + +在上一节中，你在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。 +然后用 PR 将你的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支中。 +现在，需要将你的更改反向移植到已经发布的分支。 +例如，假设 master 分支被用来开发 Kubernetes 1.10 版，并且你想将更改反向移植到 release-1.9 分支。 -回想一下，您的 pull request 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。下一步的目的是对您的第一次提交 cherry pick 到 release-1.9 分支。这个想法是 cherry pick 编辑了 types.go 的提交，但不是具有运行脚本结果的提交。有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 +回想一下，您的 PR 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。 +下一步是将你的第一次提交 cherrypick 到 release-1.9 分支。这样做的原因是仅 cherrypick 编辑了 types.go 的提交， +而不是具有脚本运行结果的提交。 +有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 {{< note >}} -提出 cherry pick 要求您有权在 pull request 中设置标签和里程碑。如果您没有这些权限，则需要与可以为您设置标签和里程碑的人员合作。 +提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果您没有这些权限， +则需要与可以为你设置标签和里程碑的人员合作。 {{< /note >}} -当您提出一个 pull request，希望将您的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9 分支中运行这些脚本。 +当你发起 PR 将你的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9 +分支中运行如下脚本。 ```shell hack/update-generated-swagger-docs.sh @@ -354,7 +359,8 @@ hack/update-api-reference-docs.sh Now add a commit to your cherry-pick pull request that has the recently generated OpenAPI spec and related files. Monitor your pull request until it gets merged into the release-1.9 branch. --> -现在将提交添加到您的 Cherry-pick pull request 中，该请求具有最近生成的 OpenAPI 规范和相关文件。关注您的 pull request 请求，直到其合并到 release-1.9 分支中为止。 +现在将提交添加到您的 Cherry-Pick PR 中，该 PR 中包含最新生成的 OpenAPI 规范和相关文件。 +关注你的 PR，直到其合并到 release-1.9 分支中为止。 -此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件，这些文件反映了您对 `types.go` 所做的更改。请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。 - +此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件， +这些文件反映了对 `types.go` 所做的更改。 +请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。 +release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。 +master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。 -## 生成已发布的参考文档 - -上一节显示了如何编辑源文件然后生成多个文件，包括在 `kubernetes/kubernetes` 代码仓库中的 `api/openapi-spec/swagger.json`。 -`swagger.json` 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。 +## 生成已发布的参考文档 + +上一节显示了如何编辑源文件然后生成多个文件，包括在 `kubernetes/kubernetes` 代码仓库中的 +`api/openapi-spec/swagger.json`。`swagger.json` 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。 -现在，您可以按照[生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)指南来生成 +现在，您可以按照 +[生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/) +指南来生成 [已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 - - ## {{% heading "whatsnext" %}} - -该页面显示了如何自动生成 `kubectl` 工具提供的命令的参考页面。 +本页面描述了如何生成 `kubectl` 命令参考。 -{{< note >}} -本主题展示了如何为 [kubectl 命令集](/docs/reference/generated/kubectl/kubectl-commands) 生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 - -本主题没有展示如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件的参考页面。相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。 + +{{< note >}} +本主题描述了如何为 [kubectl 命令](/docs/reference/generated/kubectl/kubectl-commands) +生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 +[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 +本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件选项的参考页面。 +相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。 {{< /note >}} - - - ## {{% heading "prerequisites" %}} - - - -* 你需要安装 [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 - - - -* 你需要安装 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install), 并在环境变量中设置 `$GOPATH`。 - - - -* 你需要安装 [Docker](https://docs.docker.com/engine/installation/)。 - - - -* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - +{{< include "prerequisites-ref-docs.md" >}} -## 设置本地仓库 - -创建本地工作区并设置您的 `GOPATH`。 +## 配置本地仓库 + +创建本地工作区并设置你的 `GOPATH`。 ```shell mkdir -p $HOME/ - export GOPATH=$HOME/ ``` - + 获取以下仓库的本地克隆： ```shell @@ -113,16 +72,14 @@ go get -u kubernetes-incubator/reference-docs -如果您还没有下载过 `kubernetes/website` 仓库，现在下载： +如果您还没有获取过 `kubernetes/website` 仓库，现在获取之： ```shell git clone https://github.com//website $GOPATH/src/github.com//website ``` - -克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes： + +克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes： ```shell git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes @@ -131,18 +88,15 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes -从 `$GOPATH/src/k8s.io/kubernetes/vendor/github.com` 中卸载 spf13 软件包。 +从 `$GOPATH/src/k8s.io/kubernetes/vendor/github.com` 中移除 spf13 软件包。 ```shell rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13 ``` - + kubernetes/kubernetes 仓库提供对 kubectl 和 kustomize 源代码的访问。 - -确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/k8s.io/kubernetes.`。下文将该目录称为 ``。 +* 确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。 + 例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/k8s.io/kubernetes.`。 + 下文将该目录称为 ``。 -确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com//website`。下文将该目录称为 ``。 +* 确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。 + 例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com//website`。 + 下文将该目录称为 ``。 -确定 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。下文将该目录称为 ``。 +* 确定 [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) + 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 + `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 + 下文将该目录称为 ``。 -在您当地的 k8s.io/kubernetes 仓库中，检查感兴趣的分支并确保它是最新的。例如，如果您想要生成 Kubernetes 1.15 的文档，您可以使用以下命令： +在本地的 k8s.io/kubernetes 仓库中，检出感兴趣的分支并确保它是最新的。例如， +如果你想要生成 Kubernetes 1.17 的文档，可以使用以下命令： ```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 ``` -如果不需要编辑 kubectl 源码，请按照说明[编辑 Makefile](#editing-makefile)。 +如果不需要编辑 `kubectl` +源码，请按照说明[配置构建变量](#setting-build-variables)。 -## 编辑 kubectl 源码 - - +## 编辑 kubectl 源码 -kubectl 命令集的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 +kubectl 命令的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 +kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 +[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master +分支提交 PR。 -[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl 源码中的笔误进行修复的 PR 示例。 - - -跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 master 分支中。 +[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl +源码中的笔误进行修复的 PR 示例。 + +跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 +master 分支中。 -## 以 cherry-pick 方式将你的修改合入已发布分支 - - +## 以 cherry-pick 方式将你的修改合入已发布分支 -你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。 +你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。 +如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 +cherry-pick 方式合入已发布分支。 -例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.15 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 - - +例如，假设 master 分支正用于开发 Kubernetes 1.16 版本，而你希望将修改合入到已发布的 1.15 版本分支。 +相关的操作指南，请参见 +[提议一个 cherry-pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。 + 跟踪你的 cherry-pick PR，直到它合入到已发布分支中。 -{{< note >}} -提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 +{{< note >}} +提议一个 cherry-pick 需要你有在 PR 中设置标签和里程碑的权限。 +如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 {{< /note >}} +## Setting build variables -## 编辑 Makefile - - +## 设置构建变量 {#setting-build-variables} 进入 `` 目录, 打开 `Makefile` 进行编辑： -* 设置 `K8SROOT` 为 ``。 -* 设置 `WEBROOT` 为 ``。 -* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。 +* Set `K8S_ROOT` to ``. +* Set `K8S_WEBROOT` 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. - -例如，更新以下变量： +* 设置 `K8S_ROOT` 为 ``。 +* 设置 `K8S_WEBROOT` 为 ``。 +* 设置 `K8S_RELEASE` 为要构建文档的版本。 + 例如，如果您想为 Kubernetes 1.17 构建文档，请将 `K8S_RELEASE` 设置为 1.17。 + +例如： ``` -WEBROOT=$(GOPATH)/src/github.com//website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 +export K8S_WEBROOT=$(GOPATH)/src/github.com//website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 ``` ## 创建版本目录 - -版本目录是 kubectl 命令集构建的临时区域。该目录中的 YAML 文件用于创建 kubectl 命令集参考的结构和导航。 +构建目标 `createversiondirs` 会生成一个版本目录并将 kubectl 参考配置文件复制到该目录中。 +版本目录的名字模式为 `v_`。 - - -在 `gen-kubectldocs/generators` 目录中，如果你还没有一个名为 `v1_MINOR_VERSION` 的目录，那么现在通过复制前一版本的目录来创建一个。例如，假设你想要为 Kubernetes 1.15 版本生成文档，但是还没有 `v1_15` 目录，这时可以通过运行以下命令来创建并填充 `v1_15` 目录： +在 `` 目录下，执行下面的命令： ```shell -cd -git checkout release-1.15 -git pull https://github.com/kubernetes/kubernetes release-1.15 +cd +make createversiondirs ``` -## 从 kubernetes/kubernetes 检出一个分支 - - +## 从 kubernetes/kubernetes 检出一个分支 -在本地 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。例如，如果希望为 Kubernetes 1.15 版本生成文档，请检出 1.15 分支。确保本地分支是最新的。 +在本地 `` 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。 +例如，如果希望为 Kubernetes 1.17 版本生成文档，请检出 `v1.17.0` 标记。 +确保本地分支是最新的。 ```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 ``` -## 运行文档生成代码 - - +## 运行文档生成代码 -在 kubernetes-incubator/reference-docs 仓库的本地目录中，构建并运行 kubectl 命令集参数生成代码。你可能需要以 root 用户运行命令： +在本地的 `` 目录下，运行 `copycli` 构建目标。此命令以 `root` 账号运行： ```shell cd @@ -361,16 +316,16 @@ 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 ``. --> -`copycli` 命令将清理暂存目录，生成 kubectl 命令集文件，并将整理后的 kubectl 参考 HTML 页面和文件复制到 ``。 +`copycli` 命令将清理暂存目录，生成 kubectl 命令文件，并将整理后的 kubectl 参考 HTML 页面和 +文件复制到 ``。 ## 找到生成的文件 - 验证是否已生成以下两个文件： ```shell @@ -380,22 +335,19 @@ Verify that these two files have been generated: ## 找到复制的文件 - -确认所有生成的文件都已复制到您的 ``： +确认所有生成的文件都已复制到你的 ``： ```shell cd git status ``` - + 输出应包括修改后的文件： ``` @@ -403,10 +355,9 @@ static/docs/reference/generated/kubectl/kubectl-commands.html static/docs/reference/generated/kubectl/navData.js ``` - -此外，输出可能显示修改后的文件： + + +此外，输出可能还包含： ``` static/docs/reference/generated/kubectl/scroll.js @@ -421,12 +372,11 @@ static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-aweso ## 在本地测试文档 - 在本地 `` 中构建 Kubernetes 文档。 ```shell @@ -434,55 +384,44 @@ cd make docker-serve ``` - + 查看[本地预览](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/)。 ## 在 kubernetes/website 中添加和提交更改 - 运行 `git add` 和 `git commit` 提交修改文件。 -## 创建 PR - -对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。 - - +## 创建 PR + +对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。 +继续跟踪你的 PR，直到它被合入。 在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。 - - - ## {{% heading "whatsnext" %}} - - -* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) -* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-components/) +* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md index c31b9a2909..135f8843ef 100644 --- a/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -1,21 +1,22 @@ --- title: 为 Kubernetes API 生成参考文档 content_type: task +weight: 50 --- 本页面展示了如何为 Kubernetes API 更新自动生成的参考文档。 -Kubernetes API 参考文档是从 [Kubernetes OpenAPI 规范](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)构建的，而工具是从 [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 构建的。 - -如果您在生成的文档中发现错误，则需要[将其上游修复](/docs/contribute/generate-ref-docs/contribute-upstream/)。 - -如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页面。 +Kubernetes API 参考文档是从 +[Kubernetes OpenAPI 规范](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json) +构建的，而工具是从 +[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 构建的。 +如果您在生成的文档中发现错误，则需要[在上游修复](/docs/contribute/generate-ref-docs/contribute-upstream/)。 +如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页。 ## {{% heading "prerequisites" %}} - - - -你需要安装以下软件： - - - -* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -* 1.9.1 或更高版本的 [Golang](https://golang.org/doc/install) - - -你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的 fork 分支。想了解更多信息，请参见[创建一个文档 PR](/docs/contribute/start/) 和 [GitHub 标准 Fork & PR 工作流](https://gist.github.com/Chaser324/ce0505fbed06b947d962)。 - - - +{{< include "prerequisites-ref-docs.md" >}} -## 设置本地仓库 - -创建本地工作区并设置您的 `GOPATH`。 +## 配置本地仓库 + +创建本地工作区并设置你的 `GOPATH`。 ```shell mkdir -p $HOME/ - export GOPATH=$HOME/ ``` - + 获取以下仓库的本地克隆： ```shell go get -u github.com/kubernetes-incubator/reference-docs - go get -u github.com/go-openapi/loads go get -u github.com/go-openapi/spec ``` - -如果您还没有下载过 `kubernetes/website` 仓库，现在下载： + +如果你还没有下载过 `kubernetes/website` 仓库，现在下载： ```shell git clone https://github.com//website $GOPATH/src/github.com//website ``` - -克隆下载 kubernetes/kubernetes 仓库，并作为 k8s.io/kubernetes： + +克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes： ```shell git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes @@ -125,97 +94,91 @@ The remaining steps refer to your base directory as ``. repository is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.` The remaining steps refer to your base directory as ``. --> -* [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库克隆后的基本目录为 `$GOPATH/src/k8s.io/kubernetes`。 -其余后续步骤将您的基本目录称为 ``。 - -* [kubernetes/website](https://github.com/kubernetes/website) 仓库克隆后的基本目录为 `$GOPATH/src/github.com//website`。 -其余后续步骤将您的基本目录称为 ``。 - -* [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) 仓库克隆后的基本目录为 `$GOPATH/src/github.com/kubernetes-incubator/reference-docs`。 -其余后续步骤将您的基本目录称为 ``。 +* [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库克隆后的根目录为 + `$GOPATH/src/k8s.io/kubernetes`。 后续步骤将此目录称为 ``。 +* [kubernetes/website](https://github.com/kubernetes/website) 仓库克隆后的根目录为 + `$GOPATH/src/github.com//website`。后续步骤将此目录称为 ``。 +* [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) + 仓库克隆后的基本目录为 `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`。 + 后续步骤将此目录称为 ``。 -## 生成 API 参考文档 - +## 生成 API 参考文档 + 本节说明如何生成[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 -### 修改 Makefile 文件 +### Setting build variables - -进入 `` 目录，然后编辑 `Makefile` 文件： +### 设置构建变量 {#setting-build-variables} -* 设置 `K8SROOT` 为 ``. -* 设置 `WEBROOT` 为 ``. -* 设置 `MINOR_VERSION` 为要构建的文档的次要版本。例如，如果您想为 Kubernetes 1.15 构建文档，请将 `MINOR_VERSION` 设置为 15。保存并关闭 `Makefile` 文件。 +* 设置 `K8S_ROOT` 为 ``. +* 设置 `K8S_WEBROOT` 为 ``. +* 设置 `K8S_RELEASE` 为要构建的文档的版本。 + 例如，如果您想为 Kubernetes 1.17 构建文档，请将 `K8S_RELEASE` 设置为 1.17。 - -例如，更新以下变量： + +例如： ``` -WEBROOT=$(GOPATH)/src/github.com//website -K8SROOT=$(GOPATH)/src/k8s.io/kubernetes -MINOR_VERSION=15 +export K8S_WEBROOT=$(GOPATH)/src/github.com//website +export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes +export K8S_RELEASE=1.17 ``` -### 复制 OpenAPI 规范 +### Creating versioned directory and fetching Open API spec - -在 `` 目录中运行以下命令： +### 创建版本目录并复制 OpenAPI 规范 + +构建目标 `updateapispec` 负责创建版本化的构建目录。 +目录创建了之后，从 `` 仓库取回 OpenAPI 规范文件。 +这些步骤确保配置文件的版本和 Kubernetes OpenAPI 规范的版本与发行版本匹配。 +版本化目录的名称形式为 `v_`。 ```shell make updateapispec ``` - -输出显示文件已被复制： - -```shell -cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json -``` - ### 构建 API 参考文档 - +构建目标 `copyapi` 会生成 API 参考文档并将所生成文件复制到 +`` 目录中运行以下命令： ```shell -make api +cd +make copyapi ``` - + 验证是否已生成这两个文件： ```shell @@ -223,108 +186,83 @@ Verify that these two files have been generated: [ -e "/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` - -### 创建发布文档的目录 - - -在 `` 目录中为生成的 API 参考文件创建目录： - -```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 -``` - - -## 将生成的文档复制到 kubernetes/website 仓库 - - -在 `` 目录中运行以下命令，将生成的文件复制到本地 kubernetes/website 仓库。 - -```shell -make copyapi -``` - - -进入 kubernetes/website 仓库的本地主目录，并查看已修改的文件： +进入本地 `` 目录，检查哪些文件被更改： ```shell cd git status ``` - -输出显示修改后的文件： + +输出类似于： ``` -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/{{< param "version" >}}/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2 +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/jquery.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js ``` ## 更新 API 参考索引页面 +在为新发行版本生成参考文档时，需要更新下面的文件，使之包含新的版本号： +`/content/en/docs/reference/kubernetes-api/api-index.md`。 - -* 打开 `/content/en/docs/reference/kubernetes-api/index.md` 文件进行编辑，并且更新 API 参考版本号。例如： +* 打开并编辑 `/content/en/docs/reference/kubernetes-api/api-index.md`， + API 参考的版本号。例如： ``` - --- - title: v1.15 - --- - - [Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/) + title: v1.17 + [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/) ``` - - -* 打开 `/content/en/docs/reference/_index.md` 文件进行编辑，并添加新链接以获取最新的 API 参考。移除最旧的 API 参考版本。应该有五个指向最新 API 参考的链接。 - +* 打开编辑 `/content/en/docs/reference/_index.md`，添加指向最新 API 参考 + 的链接，删除最老的 API 版本。 + 通常保留最近的五个版本的 API 参考的链接。 -## 在本地测试 API 参考 - +## 在本地测试 API 参考 + 发布 API 参考的本地版本。 -验证 [本地预览](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/)。 +检查[本地预览](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/)。 ```shell cd @@ -333,11 +271,11 @@ make docker-serve ## 提交更改 - 在 `` 中运行 `git add` 和 `git commit` 来提交更改。 -将您的更改[创建 PR](/docs/contribute/start/) 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。 - - +基于你所生成的更改[创建 PR](/docs/contribute/start/)， +提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。 +监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。 ## {{% heading "whatsnext" %}} - -* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/) -* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md index 676575d2cc..95b2794047 100644 --- a/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -1,413 +1,50 @@ --- -title: 为 Kubernetes 组件和工具生成参考页面 +title: 为 Kubernetes 组件和工具生成参考文档 content_type: task +weight: 120 --- - -本页面展示了如何使用 `update-imported-docs` 工具来为 [Kubernetes](https://github.com/kubernetes/kubernetes) 和 [Federation](https://github.com/kubernetes/federation) 仓库中的工具和组件生成参考文档。 - - +本页面描述如何构造 Kubernetes 组件和工具的参考文档。 ## {{% heading "prerequisites" %}} - - -* 你需要一个运行着 Linux 或 macOS 操作系统的机器。 - - - -* 你需要安装以下软件： - - * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - - * 1.9或更高版本的 [Golang](https://golang.org/doc/install) - - * [make](https://www.gnu.org/software/make/) - - * [gcc compiler/linker](https://gcc.gnu.org/) - - - -* 在环境变量中设置 `$GOPATH`。 - - - -* 你需要知道如何在一个 GitHub 项目仓库中创建一个 PR。一般来说，这涉及到创建仓库的一个分支。想了解更多信息，请参见[创建一个文档 PR](/docs/home/contribute/create-pull-request/)。 - - +阅读参考文档快速入门指南中的[准备工作](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 - -## 下载两个仓库 - - - -如果你还没有下载过 `kubernetes/website` 仓库，现在下载： - -```shell -mkdir $GOPATH/src -cd $GOPATH/src -go get github.com/kubernetes/website -``` - - - -确定 [kubernetes/website](https://github.com/kubernetes/website) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/website`。下文将该目录称为 ``。 - - - -如果你想对参考文档进行修改，但是你还没下载过 `kubernetes/kubernetes` 仓库，现在下载： - -```shell -mkdir $GOPATH/src -cd $GOPATH/src -go get github.com/kubernetes/kubernetes -``` - - - -确定 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 `$GOPATH/src/github.com/kubernetes/kubernetes`。下文将该目录称为 ``。 - -{{< note >}} - - -如果你只想生成参考文档，而不需要修改，则不需要手动下载 `kubernetes/kubernetes` 仓库。当你运行 `update-imported-docs` 工具时，它会自动克隆 `kubernetes/kubernetes` 仓库。 -{{< /note >}} - - - -## 编辑 Kubernetes 源码 - - - -Kubernetes 组件和工具的参考文档是基于 Kubernetes 源码自动生成的。如果想要修改参考文档，可以从修改 Kubernetes 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 的 master 分支提交 PR。 - - - -[PR 56942](https://github.com/kubernetes/kubernetes/pull/56942) 是一个对 Kubernetes 源码中的注释进行修改的 PR 示例。 - - - -跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 `kubernetes/kubernetes` 仓库的 master 分支中。 - - - -## 以 cherry-pick 方式将你的修改合入已发布分支 - - - -你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。 - - - -例如，假设 master 分支正用于开发 Kubernetes 1.10 版本，而你希望将修改合入到已发布的 1.9 版本分支。相关的操作指南，请参见 [提议一个 cherry-pick 合入](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md)。 - - - -跟踪你的 cherry-pick PR，直到它合入到已发布分支中。 - -{{< note >}} - - -提议一个 cherry-pick 合入，需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。 -{{< /note >}} - - - -## update-imported-docs 概述 - - - -`update-imported-docs` 工具在 `kubernetes/website/update-imported-docs/` 目录下。它执行以下步骤： - - - -1. 克隆配置文件中指定的相关仓库。为了生成参考文档，默认情况下克隆的仓库是 `kubernetes-incubator/reference-docs` 和 `kubernetes/federation`。 -1. 在克隆出的仓库下运行命令来准备文档生成器，然后生成 Markdown 文件。 -1. 将生成的 Markdown 文件复制到配置文件中指定的 `kubernetes/website` 仓库的本地目录中。 - - - -当 Markdown 文件放入 `kubernetes/website` 仓库的本地目录中后，你就可以创建 [PR](/docs/home/contribute/create-pull-request/) 将它们提交到 `kubernetes/website`。 - - - -## 自定义 reference.yml 配置文件 - - - -打开 `/update-imported-docs/reference.yml` 进行编辑。不要修改 `generate-command` 条目的内容，除非你了解它的作用，并且需要修改指定的已发布分支。 - -```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 -``` - - - -在 reference.yml 中，`files` 字段是 `src` 和 `dst` 字段的列表。`src` 字段指定生成的 Markdown 文件的位置，而 `dst` 字段指定将此文件复制到 `kubernetes/website` 仓库的本地目录的哪个位置。例如： - -```yaml -repos: -- name: reference-docs - remote: https://github.com/kubernetes-incubator/reference-docs.git - files: - - src: gen-compdocs/build/kube-apiserver.md - dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md - ... -``` - - - -注意，当有许多文件要从同一个源目录复制到同一个目标目录时，可以使用通配符给 `src` 赋值，而使用目录名给 `dst` 赋值。例如： - -```shell - files: - - src: gen-compdocs/build/kubeadm*.md - dst: content/en/docs/reference/setup-tools/kubeadm/generated/ -``` - - - -## 运行 update-imported-docs 工具 - - - -在检查与或自定义 `reference.yaml` 文件后，运行 `update-imported-docs` 工具： - -```shell -cd /update-imported-docs -./update-imported-docs reference.yml -``` - - - -## 在 kubernetes/website 中添加和提交修改 - - - -列出生成并准备合入到 `kubernetes/website` 仓库中的文件： - -``` -cd -git status -``` - - - -输出展示了新增和修改的文件。例如，输出可能如下所示： - -```shell -... - - modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md - modified: content/en/docs/reference/command-line-tools-reference/federation-apiserver.md - modified: content/en/docs/reference/command-line-tools-reference/federation-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 -... -``` - - - -运行 `git add` 和 `git commit` 将提交上述文件。 - - - -## 创建 PR - - - -对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。 - - - -在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。 - - +按照[参考文档快速入门](/docs/contribute/generate-ref-docs/quickstart/) +指引，生成 Kubernetes 组件和工具的参考文档。 ## {{% heading "whatsnext" %}} - -* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generated-reference/kubectl/) -* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generated-reference/kubernetes-api/) -* [为 Kubernetes 联邦 API 生成参考文档](/docs/home/contribute/generated-reference/federation-api/) +* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/) +* [为 kubectll 命令生成参考文档](/docs/home/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-api/) +* [为上游 Kubernetes 项目做贡献以改进文档](/docs/contribute/generate-ref-docs/contribute-upstream/) diff --git a/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md new file mode 100644 index 0000000000..4a52bfa997 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -0,0 +1,45 @@ + + +### 需求 {#requirements} + +- 你需要一台 Linux 或 macOS 机器。 + +- 你需要安装以下工具： + + - [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) 1.13+ 版本 + - 用来安装 PyYAML 的 [Pip](https://pypi.org/project/pip/) + - [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/) （仅用于 `kubectl` 命令参考） + + +- 你的 `PATH` 环境变量必须包含所需要的构建工具，例如 `Go` 程序和 `python`。 + +- 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 + 这牵涉到创建仓库的派生（fork）副本。 + 有关信息可进一步查看[基于本地副本开展工作](/docs/contribute/intermediate/#work_from_a_local_clone)。 + diff --git a/content/zh/docs/contribute/generate-ref-docs/quickstart.md b/content/zh/docs/contribute/generate-ref-docs/quickstart.md new file mode 100644 index 0000000000..4011b5f9b8 --- /dev/null +++ b/content/zh/docs/contribute/generate-ref-docs/quickstart.md @@ -0,0 +1,405 @@ +--- +title: 快速入门 +content_type: task +weight: 40 +--- + + + + + +本页讨论如何使用 `update-imported-docs` 脚本来生成 Kubernetes 参考文档。 +此脚本将构建的配置过程自动化，并为某个发行版本生成参考文档。 + +## {{% heading "prerequisites" %}} + +{{< include "prerequisites-ref-docs.md" >}} + + + +## 获取文档仓库 {#getting-the-docs-repository} + +确保你的 `website` 派生仓库与 `kubernetes/website` 主分支一致，并克隆 +你的派生仓库。 + +```shell +mkdir github.com +cd github.com +git clone git@github.com:/website.git +``` + + +确定你的克隆副本的根目录。例如，如果你按照前面的步骤获取了仓库，你的根目录 +会是 `github.com/website`。接下来的步骤中，`` 用来指代你的根目录。 + +{{< note>}} +如果你希望更改构建工具和 API 参考资料，可以阅读 +[上游贡献指南](/docs/contribute/generate-ref-docs/contribute-upstream). +{{< /note >}} + + +## update-imported-docs 的概述 + +脚本 `update-imported-docs` 位于 `/update-imported-docs/` 目录下， +能够生成以下参考文档： + +* Kubernetes 组件和工具的参考页面 +* `kubectl` 命令参考文档 +* Kubernetes API 参考文档 + + +脚本 `update-imported-docs` 基于 Kubernetes 源代码生成参考文档。 +过程中会在你的机器的 `/tmp` 目录下创建临时目录，克隆所需要的仓库 +`kubernetes/kubernetes` 和 `kubernetes-sigs/reference-docs` 到此临时目录。 +脚本会将 `GOPATH` 环境变量设置为指向此临时目录。 +此外，脚本会设置三个环境变量： + +* `K8S_RELEASE` +* `K8S_ROOT` +* `K8S_WEBROOT` + + +脚本需要两个参数才能成功运行： + +* 一个 YAML 配置文件（`reference.yml`） +* 一个发行版本字符串，例如：`1.17` + +配置文件中包含 `generate-command` 字段，其中定义了一系列来自于 +`kubernetes-sigs/reference-docs/Makefile` 的构建指令。 +变量 `K8S_RELEASE` 用来确定所针对的发行版本。 + + +脚本 `update-imported-docs` 执行以下步骤： + +1. 克隆配置文件中所指定的相关仓库。就生成参考文档这一目的而言，要克隆的 + 仓库默认为 `kubernetes-sigs/reference-docs`。 +1. 在所克隆的仓库下运行命令，准备文档生成器，之后生成 HTML 和 Markdown 文件。 +1. 将所生成的 HTML 和 Markdown 文件复制到 `` 本地克隆副本中， + 放在配置文件中所指定的目录下。 +1. 更新 `kubectl.md` 文件中对 `kubectl` 命令文档的链接，使之指向 `kubectl` + 命令参考中对应的节区。 + + +当所生成的文件已经被放到 `` 目录下，你就可以将其提交到你的派生副本中， +并基于所作提交发起[拉取请求（PR）](/docs/contribute/start/)到 k/website 仓库。 + + +## 配置文件格式 {#configuration-file-format} + +每个配置文件可以包含多个被导入的仓库。当必要时，你可以通过手工编辑此文件进行定制。 +你也可以通过创建新的配置文件来导入其他文档集合。 +下面是 YAML 配置文件的一个例子： + +```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 +``` + + +通过工具导入的单页面的 Markdown 文档必须遵从 +[文档样式指南](/docs/contribute/style/style-guide/)。 + + + +## 定制 reference.yml + +打开 `/update-imported-docs/reference.yml` 文件进行编辑。 +在不了解参考文档构造命令的情况下，不要更改 `generate-command` 字段的内容。 +你一般不需要更新 `reference.yml` 文件。不过也有时候上游的源代码发生变化， +导致需要对配置文件进行更改（例如：Golang 版本依赖或者第三方库发生变化）。 +如果你遇到类似问题，请在 [Kubernetes Slack 的 #sig-docs 频道](https://kubernetes.slack.com) +联系 SIG-Docs 团队。 + + + +{{< note >}} +注意，`generate-command` 是一个可选项，用来运行指定命令或者短脚本以在仓库 +内生成文档。 +{{< /note >}} + +在 `reference.yml` 文件中，`files` 属性包含了一组 `src` 和 `dst` 字段。 +`src` 字段给出在所克隆的 `kubernetes-sigs/reference-docs` 构造目录中生成的 +Markdown 文件的位置，而 `dst` 字段则给出了对应文件要复制到的、所克隆的 +`kubernetes/website` 仓库中的位置。例如： + +```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 + ... +``` + + +注意，如果从同一源目录中有很多文件要复制到目标目录，你可以在为 `src` 所设置的 +值中使用通配符。这时，为 `dst` 所设置的值必须是目录名称。例如： + +```yaml + files: + - src: gen-compdocs/build/kubeadm*.md + dst: content/en/docs/reference/setup-tools/kubeadm/generated/ +``` + + +## 运行 update-imported-docs 工具 + +你可以用如下方式运行 `update-imported-docs` 工具： + +```shell +cd /update-imported-docs +./update-imported-docs +``` + + +例如： + +```shell +./update-imported-docs reference.yml 1.17 +``` + + + +## 修复链接 + +配置文件 `release.yml` 中包含用来修复相对链接的指令。 +若要修复导入文件中的相对链接，将 `gen-absolute-links` 属性设置为 `true`。 +你可以在 [`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml) +文件中找到示例。 + + +## 添加并提交 kubernetes/website 中的变更 + +枚举新生成并复制到 `` 的文件： + +```shell +cd +git status +``` + + +输出显示新生成和已修改的文件。取决于上游源代码的修改多少， +所生成的输出也会不同。 + +### 生成的 Kubernetes 组件文档 + +``` +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 +``` + + +### 生成的 kubectl 命令参考文件 + +``` +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 +``` + + +### 生成的 Kubernetes API 参考目录与文件 + +``` +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/query.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2 +``` + + +运行 `git add` 和 `git commit` 提交文件。 + +## 创建拉取请求 {#creating-a-pull-request} + +接下来创建一个对 `kubernetes/website` 仓库的拉取请求（PR）。 +监视所创建的 PR，并根据需要对评阅意见给出反馈。 +继续监视该 PR 直到其被合并为止。 + +当你的 PR 被合并几分钟之后，你所做的对参考文档的变更就会出现 +[发布的文档](/docs/home/)上。 + +## {{% heading "whatsnext" %}} + + +要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南： + +* [为 Kubernetes 组件和工具生成参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubeclt 命令生成参考文档](/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/) + From 7eef8e73babba1a7eaf8be6d1413db3136805861 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 23 Jun 2020 10:49:32 +0800 Subject: [PATCH 18/99] [zh] Sync contribution guidelines (5) This PR is about the reviews. --- content/zh/docs/contribute/review/_index.md | 17 + .../docs/contribute/review/for-approvers.md | 432 ++++++++++++++++++ .../docs/contribute/review/reviewing-prs.md | 202 ++++++++ 3 files changed, 651 insertions(+) create mode 100644 content/zh/docs/contribute/review/_index.md create mode 100644 content/zh/docs/contribute/review/for-approvers.md create mode 100644 content/zh/docs/contribute/review/reviewing-prs.md diff --git a/content/zh/docs/contribute/review/_index.md b/content/zh/docs/contribute/review/_index.md new file mode 100644 index 0000000000..b3401268bb --- /dev/null +++ b/content/zh/docs/contribute/review/_index.md @@ -0,0 +1,17 @@ +--- +title: 评阅变更 +weight: 30 +--- + + + + +本节描述如何对内容进行评阅。 + + + diff --git a/content/zh/docs/contribute/review/for-approvers.md b/content/zh/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..3db894e0b4 --- /dev/null +++ b/content/zh/docs/contribute/review/for-approvers.md @@ -0,0 +1,432 @@ +--- +title: 评阅人和批准人文档 +linktitle: 评阅人和批准人 +slug: for-approvers +content_type: concept +weight: 20 +--- + + + + +SIG Docs [评阅人（Reviewers）](/docs/contribute/participating/#reviewers) +和[批准人（Approvers）](/docs/contribute/participating/#approvers) +在对变更进行评审时需要做一些额外的事情。 + +每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。 +此角色称作该周的“PR 管理者（PR Wrangler）”。 +相关信息可参考 [PR Wrangler 排班表](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 +要成为 PR Wangler，需要参加每周的 SIG Docs 例会，并自愿报名。 +即使当前这周排班没有轮到你，你仍可以评阅那些尚未被积极评阅的 PRs。 + +除了上述的轮值安排，后台机器人也会为基于所影响的文件来为 PR +指派评阅人和批准人。 + + + +## 评阅 PR + +Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。 + +[评阅 PR](/docs/contribute/review/reviewing-prs) 文档中所描述的所有规程都适用， +不过评阅人和批准人还要做以下工作： + + +- 根据需要使用 Prow 命令 `/assign` 指派特定的评阅人。如果某个 PR + 需要来自代码贡献者的技术审核时，这一点非常重要。 + + {{< note >}} + 你可以查看 Markdown 文件的文件头，其中的 `reviewers` 字段给出了哪些人可以为文档提供技术审核。 + {{< /note >}} + +- 确保 PR 遵从[内容指南](/docs/contribute/style/content-guide/)和[样式指南](/docs/contribute/style/style-guide/)； + 如果 PR 没有达到要求，指引作者阅读指南中的相关部分。 +- 适当的时候使用 GitHub **Request Changes** 选项，建议 PR 作者实施所建议的修改。 +- 当你所提供的建议被采纳后，在 GitHub 中使用 `/approve` 或 `/lgtm` Prow 命令，改变评审状态。 + + +## 提交到他人的 PR + +为 PR 留下评语是很有用的，不过有时候你需要向他人的 PR 提交内容。 + +除非他人明确请求你的帮助或者你希望重启一个被放弃很久的 PR，不要“接手”他人的工作。 +尽管短期看来这样做可以提高效率，但是也剥夺了他人提交贡献的机会。 + +你所要遵循的流程取决于你需要编辑已经在 PR 范畴的文件，还是 PR 尚未触碰的文件。 + + +如果处于下列情况之一，你不可以向别人的 PR 提交内容： + +- 如果 PR 作者是直接将自己的分支提交到 + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + 仓库。只有具有推送权限的评阅人才可以向他人的 PR 提交内容。 + + {{< note >}} + 我们应鼓励作者下次将分支推送到自己的克隆副本之后再发起 PR。 + {{< /note >}} + +- PR 作者明确地禁止批准人编辑他/她的 PR。 + + +## 评阅用的 Prow 命令 + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) +是基于 Kubernetes 的 CI/CD 系统，基于拉取请求（PR）的触发运行不同任务。 +Prow 使得我们可以使用会话机器人一样的命令跨整个 Kubernetes 组织处理 GitHub +动作，例如[添加和删除标签](#adding-and-removing-issue-labels)、关闭 Issues +以及指派批准人等等。你可以使用 `/<命令名称>` 的形式以 GitHub 评论的方式输入 +Prow 命令。 + +评阅人和批准人最常用的 Prow 命令有： + + +{{< table caption="评阅用 Prow 命令" >}} +Prow 命令 | 角色限制 | 描述 +:------------|:------------------|:----------- +`/lgtm` | 任何人均可使用，但只有评阅人和批准人使用此命令的时候才会触发自动化操作 | 用来表明你已经完成 PR 的评阅并对其所作变更表示满意 +`/approve` | 批准人 | 批准某 PR 可以合并 +`/assign` |评阅人或批准人 | 指派某人来评阅或批准某 PR +`/close` | 评阅人或批准人 | 关闭 Issue 或 PR +`/hold` | 任何人 | 添加 `do-not-merge/hold` 标签，用来表明 PR 不应被自动合并 +`/hold cancel` | 任何人 | 去掉 `do-not-merge/hold` 标签 +{{< /table >}} + +请参考 [Prow 命令指南](https://prow.k8s.io/command-help)，了解你可以在 PR +中使用的命令的完整列表。 + + +## 对 Issue 进行诊断和分类 + +一般而言，SIG Docs 遵从 [Kubernetes issue 判定](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 流程并使用相同的标签。 + +此 GitHub Issue +[过滤器](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) +可以用来查找需要评判的 Issues。 + + + +### 评判 Issue {#triaging-an-issue} + +1. 验证 Issue 的合法性 + + - 确保 Issue 是关于网站文档的。某些 Issue 可以通过回答问题或者为报告者提供 + 资源链接来快速关闭。 + 参考[请求支持或代码缺陷报告](#support-requests-or-code-bug-reports) + 节以了解详细信息。 + - 评估该 Issue 是否有价值。 + - 如果 Issue 缺少足够的细节以至于无法采取行动，或者报告者没有通过模版提供 + 足够信息，可以添加 `triage/needs-information` 标签。 + - 如果 Issue 同时标注了 `lifecycle/stale` 和 `triage/needs-information` + 标签，可以直接关闭。 + + +2. 添加优先级标签（ + [Issue 判定指南](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)中有优先级标签的详细定义) + + {{< table caption="Issue 标签" >}} + 标签 | 描述 + :------------|:------------------ + `priority/critical-urgent` | 应马上处理 + `priority/important-soon` | 应在 3 个月内处理 + `priority/important-longterm` | 应在 6 个月内处理 + `priority/backlog` | 可无限期地推迟，可在人手充足时处理 + `priority/awaiting-more-evidence` | 占位符，标示 Issue 可能是一个不错的 Issue，避免该 Issue 被忽略或遗忘 + `help` or `good first issue` | 适合对 Kubernetes 或 SIG Docs 经验较少的贡献者来处理。更多信息可参考[需要帮助和入门候选 Issue 标签](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)。 + {{< /table >}} + + 基于你自己的判断，你可以选择某 Issue 来处理，为之发起 PR + （尤其是那些可以很快处理或与你已经在做的工作相关的 Issue）。 + +如果你对 Issue 评判有任何问题，可以在 `#sig-docs` Slack 频道或者 +[kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +中提问。 + + +## 添加和删除 Issue 标签 {#adding-and-removing-issue-labels} + +要添加标签，可以用以下形式对 PR 进行评论： + +- `/<要添加的标签>` （例如, `/good-first-issue`） +- `/<标签类别> <要添加的标签>` （例如，`/triage needs-information` 或 `/language ja`） + +要移除某个标签，可以用以下形式对 PR 进行评论： + +- `/remove-<要移除的标签>` （例如，`/remove-help`） +- `/remove-<标签类别> <要移除的标签>` （例如，`/remove-triage needs-information`） + + +在以上两种情况下，标签都必须合法存在。如果你尝试添加一个尚不存在的标签， +对应的命令会被悄悄忽略。 + +关于所有标签的完整列表，可以参考 +[Website 仓库的标签节](https://github.com/kubernetes/website/labels)。 +实际上，SIG Docs 并没有使用全部标签。 + + +### Issue 生命周期标签 + +Issues 通常都可以快速创建并关闭。 +不过也有些时候，某个 Issue 被创建之后会长期处于非活跃状态。 +也有一些时候，即使超过 90 天，某个 Issue 仍应保持打开状态。 + +{{< table caption="Issue 生命周期标签" >}} +标签 | 描述 +:------------|:------------------ +`lifecycle/stale` | 过去 90 天内某 Issue 无人问津，会被自动标记为停滞状态。如果 Issue 没有被 `/remove-lifecycle stale` 命令重置生命期，就会被自动关闭。 +`lifecycle/frozen` | 对应的 Issue 即使超过 90 天仍无人处理也不会进入停滞状态。用户手动添加此标签给一些需要保持打开状态超过 90 天的 Issue，例如那些带有 `priority/important-longterm` 标签的 Issue。 +{{< /table >}} + + +## 处理特殊的 Issue 类型 {#handling-special-issue-types} + +SIG Docs 常常会遇到以下类型的 Issue，因此对其处理方式描述如下。 + +### 重复的 Issue {#duplicate-issues} + +如果针对同一个问题有不止一个打开的 Issue，可以将其合并为一个 Issue。 +你需要决定保留哪个 Issue 为打开状态（或者重新登记一个新的 Issue）， +然后将所有相关的信息复制过去并提供对关联 Issues 的链接。 +最后，将所有其他描述同一问题的 Issue 标记为 `triage/duplicate` 并关闭之。 +保持只有一个 Issue 待处理有助于减少困惑，避免在同一问题上发生重复劳动。 + + +### 失效链接 Issues {#dead-link-issues} + +如果失效链接是关于 API 或者 `kubectl` 文档的，可以将其标记为 +`/priority critical-urgent`，直到问题原因被弄清楚为止。 +对于其他的链接失效问题，可以标记 `/priority important-longterm`， +因为这些问题都需要手动处理。 + +### 博客问题 {#blog-issues} + +我们预期 [Kubernetes 博客](https://kubernetes.io/blog/)条目随着时间推移都会过期。 +因此，我们只维护一年内的博客条目。 +如果某个 Issue 是与某个超过一年的博客条目有关的，可以直接关闭 +Issue，不必修复。 + + +### 请求支持或代码缺陷报告 {#support-requests-or-code-bug-reports} + +某些文档 Issues 实际上是关于底层代码的 Issue 或者在某方面请求协助的问题， +例如某个教程无法正常工作。 +对于与文档无关的 Issues，关闭它并打上标签 `triage/support`，可以通过评论 +告知请求者其他支持渠道（Slack、Stack Overflow）。 +如果有相关的其他仓库，可以告诉请求者应该在哪个仓库登记与功能特性相关的 Issues +（通常会是 `kubernetes/kubernetes`）。 + +下面是对支持请求的回复示例： + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](http://slack.k8s.io/). You can also search +resources like +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in +https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + + +对代码缺陷 Issue 的回复示例： + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + diff --git a/content/zh/docs/contribute/review/reviewing-prs.md b/content/zh/docs/contribute/review/reviewing-prs.md new file mode 100644 index 0000000000..cc93511a8b --- /dev/null +++ b/content/zh/docs/contribute/review/reviewing-prs.md @@ -0,0 +1,202 @@ +--- +title: 评阅 PRs +content_type: concept +main_menu: true +weight: 10 +--- + + + + +任何人均可评阅文档的拉取请求。访问 Kubernetes 网站仓库的 +[pull requests](https://github.com/kubernetes/website/pulls) +部分可以查看所有待处理的拉取请求（PRs）。 + +评阅文档 PR 是将你自己介绍给 Kubernetes 社区的一种很好的方式。 +它将有助于你学习代码库并与其他贡献者之间建立相互信任关系。 + +在评阅之前，可以考虑： + +- 阅读[内容指南](/docs/contribute/style/content-guide/)和 + [样式指南](/docs/contribute/style/style-guide/)以便给出有价值的评论。 +- 了解 Kubernetes 文档社区中不同的[角色和职责](/docs/contribute/participating/#roles-and-responsibilities)。 + + + +## 准备工作 {#before-you-begin} + +在你开始评阅之前： + +- 阅读 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) + 确保你会始终遵从其中约定； +- 保持有礼貌、体谅他人，怀助人为乐初心； +- 评论时若给出修改建议，也要兼顾 PR 的积极方面 +- 保持同理心，多考虑他人收到评阅意见时的可能反应 +- 假定大家都是好意的，通过问问题澄清意图 +- 如果你是有经验的贡献者，请考虑和新贡献者一起合作，提高其产出质量 + + +## 评阅过程 {#review-process} + +一般而言，应该使用英语来评阅 PR 的内容和样式。 + +1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)， + 你会看到所有针对 Kubernetes 网站和文档的待处理 PRs。 + +2. 使用以下标签（组合）对待处理 PRs 进行过滤： + + - `cncf-cla: yes` （建议）：由尚未签署 CLA 的贡献者所发起的 PRs 不可以合并。 + 参考[签署 CLA](/docs/contribute/new-content/overview/#sign-the-cla) 以了解更多信息。 + - `language/en` （建议）：仅查看英语语言的 PRs。 + - `size/<尺寸>`：过滤特定尺寸（规模）的 PRs。如果你刚入门，可以从较小的 PR 开始。 + + 此外，确保 PR 没有标记为尚未完成（Work in Progress）。 + 包含 `work in progress` 的 PRs 通常还没准备好被评阅。 + + +3. 选定 PR 评阅之后，可以通过以下方式理解所作的变更： + + - 阅读 PR 描述以理解所作变更，并且阅读所有关联的 Issues + - 阅读其他评阅人给出的评论 + - 点击 **Files changed** Tab 页面，查看被改变的文件和代码行 + - 滚动到 **Conversation** Tab 页面下端的 PR 构建检查节区，点击 + **deploy/netlify** 行的 **Details** 链接，预览 Netlify + 预览构建所生成的结果 + +4. 前往 **Files changed** Tab 页面，开始你的评阅工作 + + 1. 点击你希望评论的行旁边的 `+` 号 + 2. 填写你对该行的评论，之后或者选择**Add single comment** （如果你只有一条评论） + 或者 **Start a review** （如果你还有其他评论要添加） + 3. 评论结束时，点击页面顶部的 **Review changes**。这里你可以添加你的评论结语 + （记得留下一些正能量的评论！）、根据需要批准 PR、请求作者进一步修改等等。 + 新手应该选择 **Comment**。 + + +## 评阅清单 {#reviewing-checklist} + +评阅 PR 时可以从下面的条目入手。 + +### 语言和语法 {#language-and-grammar} + +- 是否存在明显的语言或语法错误？对某事的描述有更好的方式？ +- 是否存在一些过于复杂晦涩的用词，本可以用简单词汇来代替？ +- 是否有些用词、术语或短语可以用不带歧视性的表达方式代替？ +- 用词和大小写方面是否遵从了[样式指南](/docs/contribute/style/style-guide/)？ +- 是否有些句子太长，可以改得更短、更简单？ +- 是否某些段落过长，可以考虑使用列表或者表格来表达？ + + +### 内容 {#content} + +- Kubernetes 网站上是否别处已经存在类似的内容？ +- 内容本身是否过度依赖于网站范畴之外、独立供应商或者非开源的文档？ + + +### 网站 {#Website} + +- PR 是否改变或者删除了某页面的标题、slug/别名或者链接锚点？ + 如果是这样，PR 是否会导致出现新的失效链接？ + 是否有其他的办法，比如改变页面标题但不改变其 slug？ +- PR 是否引入新的页面？如果是： + - 该页面是否使用了正确的[页面内容类型](/docs/contribute/style/page-content-types/) + 及相关联的 Hugo 短代码（shortcodes）？ + - 该页面能否在对应章节的侧面导航中显示？显示得正确么？ + - 该页面是否应出现在[网站主页面](/docs/home/)的列表中？ +- 变更是否正确出现在 Netlify 预览中了？ + 要对列表、代码段、表格、注释和图像等元素格外留心 + +### 其他 {#other} + +对于 PR 中的小问题，例如拼写错误或者空格问题，可以在你的评论前面加上 `nit:`。 +这样做可以让作者知道该问题不是一个不得了的大问题。 + From 1822626398bc1cbdd86e830fd68afa428a98c81d Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 8 Jul 2020 00:38:22 +0300 Subject: [PATCH 19/99] fix tooltip overflows --- static/css/custom-jekyll/tags.css | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/static/css/custom-jekyll/tags.css b/static/css/custom-jekyll/tags.css index 3b929925e8..1ff6d12e85 100644 --- a/static/css/custom-jekyll/tags.css +++ b/static/css/custom-jekyll/tags.css @@ -27,7 +27,7 @@ /* Position the tooltip text */ position: absolute; - z-index: 1; + z-index: 10; bottom: 125%; left: 50%; margin-left: -150px; From fc3c00215d2245eca67b6162d00f8c4df6aea467 Mon Sep 17 00:00:00 2001 From: Muhammad Panji Date: Wed, 8 Jul 2020 07:31:53 +0700 Subject: [PATCH 20/99] Rearrange paragraphs in iptabels bridged traffic section in install kubeadm --- .../production-environment/tools/kubeadm/install-kubeadm.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 1e504eb40d..2996568369 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 @@ -54,6 +54,8 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t ## Letting iptables see bridged traffic +Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. + As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. ```bash @@ -64,8 +66,6 @@ EOF sudo sysctl --system ``` -Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. - For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports From 0f30bc04db4187bc7f69543d4b2f82eccabb7cb8 Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Thu, 2 Jul 2020 08:41:28 -0700 Subject: [PATCH 21/99] Fix display of dropdown on case studies --- assets/scss/_custom.scss | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index f02d6d908b..202c50393c 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -108,6 +108,10 @@ section { &.dropdown:hover { color: $medium-grey; + + .dropdown-menu { + display: block; + } } } } @@ -390,4 +394,4 @@ main.content { } } } -} +} \ No newline at end of file From 086e8a60f2ac87e4abe42deea1e054981c070751 Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Tue, 7 Jul 2020 16:33:22 -0700 Subject: [PATCH 22/99] Use bootstrap right alignment --- assets/scss/_custom.scss | 12 ------------ layouts/partials/navbar-lang-selector.html | 10 ++++++++++ layouts/partials/navbar-version-selector.html | 6 +++--- 3 files changed, 13 insertions(+), 15 deletions(-) create mode 100644 layouts/partials/navbar-lang-selector.html diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 202c50393c..1921e19067 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -101,18 +101,6 @@ section { left: 0; background: #fff; } - - .dropdown-menu { - left: -80px; - } - - &.dropdown:hover { - color: $medium-grey; - - .dropdown-menu { - display: block; - } - } } } diff --git a/layouts/partials/navbar-lang-selector.html b/layouts/partials/navbar-lang-selector.html new file mode 100644 index 0000000000..7459c621c3 --- /dev/null +++ b/layouts/partials/navbar-lang-selector.html @@ -0,0 +1,10 @@ +{{/* Link directly to documentation etc., if possible. */}} +{{ $langPage := cond (gt (len .Translations) 0) . .Site.Home }} + +
+ {{ range $langPage.Translations }} + {{ .Language.LanguageName }} + {{ end }} +
\ No newline at end of file diff --git a/layouts/partials/navbar-version-selector.html b/layouts/partials/navbar-version-selector.html index dfded2b553..5a3f03e126 100644 --- a/layouts/partials/navbar-version-selector.html +++ b/layouts/partials/navbar-version-selector.html @@ -1,8 +1,8 @@ -
+
{{ range .Site.Params.versions }} {{ .version }} {{ end }} -
+
\ No newline at end of file From f9e2439e56e078bbdbdca97cf44eec2b6057c25d Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Tue, 7 Jul 2020 17:42:51 -0700 Subject: [PATCH 23/99] Include scripts.html in case studies template --- layouts/case-studies/single-baseof.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/layouts/case-studies/single-baseof.html b/layouts/case-studies/single-baseof.html index e97cbf934d..64b48a4e13 100644 --- a/layouts/case-studies/single-baseof.html +++ b/layouts/case-studies/single-baseof.html @@ -9,5 +9,7 @@ {{ partialCached "footer.html" . }} + {{ partialCached "scripts.html" . }} + \ No newline at end of file From 67fc065ae8ebdb8f62afcc4b17d7ee12dd04bba3 Mon Sep 17 00:00:00 2001 From: jianz Date: Wed, 8 Jul 2020 11:12:42 +0800 Subject: [PATCH 24/99] escape the angle brackets in the table. escape the angle brackets in order to to show the word inside table. --- content/en/docs/reference/using-api/api-concepts.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 3c41c70116..f2109071a1 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -726,11 +726,11 @@ For get and list, the semantics of resource version are: **List:** -| 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` | +| 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: From e3da1ce1be8698937fea30e2e361aa658569f696 Mon Sep 17 00:00:00 2001 From: Irvi Firqotul Aini Date: Mon, 6 Jul 2020 20:36:48 +0700 Subject: [PATCH 25/99] docs: Translate Add External IP Address Tutorial --- .../tutorials/stateless-application/_index.md | 5 + .../expose-external-ip-address.md | 173 ++++++++++++++++++ .../service/load-balancer-example.yaml | 21 +++ 3 files changed, 199 insertions(+) create mode 100644 content/id/docs/tutorials/stateless-application/_index.md create mode 100644 content/id/docs/tutorials/stateless-application/expose-external-ip-address.md create mode 100644 content/id/examples/service/load-balancer-example.yaml diff --git a/content/id/docs/tutorials/stateless-application/_index.md b/content/id/docs/tutorials/stateless-application/_index.md new file mode 100644 index 0000000000..6923ee8165 --- /dev/null +++ b/content/id/docs/tutorials/stateless-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "Aplikasi Stateless" +weight: 40 +--- + diff --git a/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md new file mode 100644 index 0000000000..df297f4c63 --- /dev/null +++ b/content/id/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -0,0 +1,173 @@ +--- +title: Mengekspos Alamat IP Eksternal untuk Mengakses Aplikasi di dalam Klaster +content_type: tutorial +weight: 10 +--- + + + +Dokumen ini menjelaskan bagaimana cara membuat objek Service Kubernetes +yang mengekspos alamat IP eksternal. + + + + +## {{% heading "prerequisites" %}} + + + * Instal [kubectl](/id/docs/tasks/tools/install-kubectl/). + + * Gunakan sebuah penyedia layanan cloud seperti Google Kubernetes Engine atau Amazon Web Services + untuk membuat sebuah klaster Kubernetes. Tutorial ini membuat sebuah + [_load balancer_ eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/), + yang membutuhkan sebuah penyedia layanan cloud. + + * Konfigurasi `kubectl` agar dapat berkomunikasi dengan Kubernetes API Server kamu. + Untuk informasi lebih lanjut, kamu dapat merujuk pada dokumentasi penyedia layanan cloud + yang kamu gunakan. + + + +## {{% heading "objectives" %}} + +* Jalankan lima buah instans dari aplikasi Hello World. +* Buatlah sebuah objek Service yang mengekspos sebuah alamat IP eksternal. +* Gunakan sebuah objek Service untuk mengakses aplikasi yang sedang dijalankan. + + + + + +## Membuat sebuah objek Service untuk sebuah aplikasi yang dijalankan pada lima buah Pod + +1. Jalankan sebuah aplikasi Hello World pada klaster kamu: + +{{< codenew file="service/load-balancer-example.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml +``` + + +Perintah di atas akan membuat sebuah + objek [Deployment](/id/docs/concepts/workloads/controllers/deployment/) + dan sebuah objek + [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) + yang diasosiasikan dengan Deployment yang dibuat. ReplicaSet memiliki lima buah + [Pod](/id/docs/concepts/workloads/pods/pod/), + yang masing-masing dari Pod tersebut menjalankan aplikasi Hello World. + +1. Tampilkan informasi mengenai Deployment: + + kubectl get deployments hello-world + kubectl describe deployments hello-world + +1. Tampilkan informasi mengenai objek ReplicaSet: + + kubectl get replicasets + kubectl describe replicasets + +1. Buatlah sebuah objek Service yang mengekspos deployment: + + kubectl expose deployment hello-world --type=LoadBalancer --name=my-service + +1. Tampilkan informasi mengenai Service: + + kubectl get services my-service + + Keluaran dari perintah di atas akan menyerupai tampilan berikut: + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s + + {{< note >}} + + Service dengan `type=LoadBalancer` didukung oleh penyedia layanan cloud eksternal, yang tidak tercakup dalam contoh ini, silahkan merujuk pada [laman berikut](/id/docs/concepts/services-networking/service/#loadbalancer) untuk informasi lebih lanjut. + + {{< /note >}} + + {{< note >}} + + Jika sebuah alamat IP eksternal yang ditunjukkan dalam status \, tunggulah hingga satu menit kemudian masukkan perintah yang sama lagi. + + {{< /note >}} + +1. Tampilkan informasi detail mengenai Service: + + kubectl describe services my-service + + Perintah di atas akan menampilkan keluaran sebagai berikut: + + Name: my-service + Namespace: default + Labels: app.kubernetes.io/name=load-balancer-example + Annotations: + Selector: app.kubernetes.io/name=load-balancer-example + Type: LoadBalancer + IP: 10.3.245.137 + LoadBalancer Ingress: 104.198.205.71 + Port: 8080/TCP + NodePort: 32377/TCP + Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... + Session Affinity: None + Events: + + Pastikan nilai dari alamat IP eksternal (`LoadBalancer Ingress`) diekspos + pada Service yang kamu buat. Pada contoh ini, alamat IP eksternal yang diberikan adalah 104.198.205.71. + Kemudian pastikan nilai dari `Port` dan `NodePort`. Pada contoh ini, `Port` + yang digunakan adalah 8080 dan `NodePort` adalah 32377. + +1. Pada keluaran perintah sebelumnya, kamu dapat melihat beberapa Service dengan beberapa endpoint: + 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 lainnya. Berikut ini merupakan alamat IP dari Pod + dimana aplikasi tersebut dijalankan. Untuk melakukan verifikasi alamat-alamat IP yang digunakan oleh Pod, + masukkan perintah berikut: + + kubectl get pods --output=wide + + Keluaran yang diberikan akan menyerupai: + + NAME ... IP NODE + hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a + hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc + +1. Gunakan alamat IP eksternal (`LoadBalancer Ingress`) untuk mengakses aplikasi Hello World: + + curl http://: + + dimana `` adalah alamat IP eksternal (`LoadBalancer Ingress`) + dari Service kamu, dan `` adalah nilai dari `Port` dari deskripsi Service kamu. + Jika kamu menggunakan minikube, menuliskan perintah `minikube service my-service` akan + secara otomatis membuka aplikasi Hello World pada _browser_. + + Respons yang diberikan apabila permintaan ini berhasil adalah sebuah pesan sapaan: + + Hello Kubernetes! + + + + +## {{% heading "cleanup" %}} + + +Untuk menghapus Service, kamu dapat menggunakan perintah ini: + + kubectl delete services my-service + +Untuk menghapus Deployment, ReplicaSet, dan Pod-Pod yang digunakan untuk +menjalankan aplikasi Hello World, kamu dapat memasukkan perintah berikut: + + kubectl delete deployment hello-world + + + + +## {{% heading "whatsnext" %}} + + +Pelajari lebih lanjut cara untuk +[menghubungkan aplikasi dengan berbagai Service](/id/docs/concepts/services-networking/connect-applications-service/). + + diff --git a/content/id/examples/service/load-balancer-example.yaml b/content/id/examples/service/load-balancer-example.yaml new file mode 100644 index 0000000000..ea88fd1548 --- /dev/null +++ b/content/id/examples/service/load-balancer-example.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: load-balancer-example + name: hello-world +spec: + replicas: 5 + selector: + matchLabels: + app.kubernetes.io/name: load-balancer-example + template: + metadata: + labels: + app.kubernetes.io/name: load-balancer-example + spec: + containers: + - image: gcr.io/google-samples/node-hello:1.0 + name: hello-world + ports: + - containerPort: 8080 From 37b1f94fe49a4956e05ae42fe1d50bf0f9fffb9f Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Wed, 8 Jul 2020 09:48:16 -0700 Subject: [PATCH 26/99] Revert T "version_menu" --- layouts/partials/navbar-version-selector.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/layouts/partials/navbar-version-selector.html b/layouts/partials/navbar-version-selector.html index 5a3f03e126..09e872053f 100644 --- a/layouts/partials/navbar-version-selector.html +++ b/layouts/partials/navbar-version-selector.html @@ -1,5 +1,5 @@
{{ range .Site.Params.versions }} From 6cb4abbe3190f24c812bc0cc60145dc88a0ecf5d Mon Sep 17 00:00:00 2001 From: wxsm Date: Thu, 9 Jul 2020 09:34:20 +0800 Subject: [PATCH 27/99] fix: zh docs mislead to en link. original link `/docs/getting-started-guides/minikube` is redirecting to `/docs/setup/`, which I think is not proper. so I change it to `/zh/docs/setup/learning-environment/minikube/`. --- content/zh/includes/task-tutorial-prereqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/includes/task-tutorial-prereqs.md b/content/zh/includes/task-tutorial-prereqs.md index a9de9e7844..acd083bde5 100644 --- a/content/zh/includes/task-tutorial-prereqs.md +++ b/content/zh/includes/task-tutorial-prereqs.md @@ -1,5 +1,5 @@ 你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 -如果你还没有集群，你可以通过 [Minikube](/docs/getting-started-guides/minikube) 构建一 +如果你还没有集群，你可以通过 [Minikube](/zh/docs/setup/learning-environment/minikube/) 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建： -请参阅[安装 Minikube](/docs/tasks/tools/install-minikube/)。 +请参阅[安装 Minikube](/zh/docs/tasks/tools/install-minikube/)。 From f8de42868f64f00ed5b50a9be190a3b1c9ee7e89 Mon Sep 17 00:00:00 2001 From: SataQiu <1527062125@qq.com> Date: Thu, 9 Jul 2020 14:19:20 +0800 Subject: [PATCH 30/99] mark docker-serve as deprecated in the docs --- content/en/docs/contribute/generate-ref-docs/kubectl.md | 3 +++ .../en/docs/contribute/generate-ref-docs/kubernetes-api.md | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md index f057ce6800..a1fed1642e 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md @@ -237,6 +237,9 @@ Build the Kubernetes documentation in your local ``. cd make docker-serve ``` +{{< note >}} +The use of `make docker-serve` is deprecated. Please use `make container-serve` instead. +{{< /note >}} View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/). 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 10482eda97..f68d81dfb4 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -185,6 +185,10 @@ cd make docker-serve ``` +{{< note >}} +The use of `make docker-serve` is deprecated. Please use `make container-serve` instead. +{{< /note >}} + ## Commit the changes In `` run `git add` and `git commit` to commit the change. From 66599808bfb386acf8912c921e83266bd82b978a Mon Sep 17 00:00:00 2001 From: SataQiu <1527062125@qq.com> Date: Thu, 9 Jul 2020 14:54:56 +0800 Subject: [PATCH 31/99] fix wrong note shortcode --- .../participate/roles-and-responsibilties.md | 8 ++++---- .../participate/roles-and-responsibilties.md | 16 ++++++++-------- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md index b01beec352..e79b9a56b5 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilties.md @@ -126,9 +126,9 @@ To apply: [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. - {{ note }} + {{< note >}} If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. - {{ /note }} + {{< /note >}} 2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). @@ -182,9 +182,9 @@ To apply: 1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. - {{ note }} + {{< note >}} If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. - {{ /note }} + {{< /note >}} 2. Assign the PR to one or more current SIG Docs approvers. diff --git a/content/zh/docs/contribute/participate/roles-and-responsibilties.md b/content/zh/docs/contribute/participate/roles-and-responsibilties.md index 388029030e..313c1ff5a4 100644 --- a/content/zh/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/zh/docs/contribute/participate/roles-and-responsibilties.md @@ -271,9 +271,9 @@ To apply: [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. - {{ note }} + {{< note >}} If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. - {{ /note }} + {{< /note >}} 2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). @@ -283,9 +283,9 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 文件的特定节。 - {{ note }} + {{< note >}} 如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-reviews`。 - {{ /note }} + {{< /note >}} 2. 将 PR 指派给一个或多个 SIG Docs 批准人（`sig-docs-{language}-owners` 下列举的用户名）。 @@ -383,9 +383,9 @@ To apply: 1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. - {{ note }} + {{< note >}} If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. - {{ /note }} + {{< /note >}} 2. Assign the PR to one or more current SIG Docs approvers. @@ -397,9 +397,9 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 文件的对应节区。 - {{ note }} + {{< note >}} 如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-owners` 中。 - {{ /note }} + {{< /note >}} 2. 将 PR 指派给一个或多个 SIG Docs 批准人。 From 9799d0ff250b978dfe66f1cffb6c89e216d387aa Mon Sep 17 00:00:00 2001 From: Rael Garcia Date: Thu, 9 Jul 2020 09:36:02 +0200 Subject: [PATCH 32/99] Add content/es/docs/concepts/overview/components.md (#22259) * Add content/es/docs/concepts/overview/components.md * Apply #14678 suggestions * Replace content_template with content_type * Remove capture shortcode * Add missing glossary terms Add controller glossary term Add etcd glossary term Add kube-apiserver glossary term Add kube-controller-manager glossary term Add kube-sccheduler glossary term Add namespace glossary term * Remove `master` references * Apply emedina suggestions Co-authored-by: Enrique Medina Montenegro Co-authored-by: Jose Miguel Parrella Co-authored-by: Enrique Medina Montenegro --- .../es/docs/concepts/overview/components.md | 117 ++++++++++++++++++ .../es/docs/reference/glossary/controller.md | 33 +++++ content/es/docs/reference/glossary/etcd.md | 24 ++++ .../docs/reference/glossary/kube-apiserver.md | 26 ++++ .../glossary/kube-controller-manager.md | 21 ++++ .../docs/reference/glossary/kube-scheduler.md | 25 ++++ .../es/docs/reference/glossary/namespace.md | 22 ++++ 7 files changed, 268 insertions(+) create mode 100644 content/es/docs/concepts/overview/components.md create mode 100755 content/es/docs/reference/glossary/controller.md create mode 100755 content/es/docs/reference/glossary/etcd.md create mode 100755 content/es/docs/reference/glossary/kube-apiserver.md create mode 100755 content/es/docs/reference/glossary/kube-controller-manager.md create mode 100755 content/es/docs/reference/glossary/kube-scheduler.md create mode 100755 content/es/docs/reference/glossary/namespace.md diff --git a/content/es/docs/concepts/overview/components.md b/content/es/docs/concepts/overview/components.md new file mode 100644 index 0000000000..0ca6f3126c --- /dev/null +++ b/content/es/docs/concepts/overview/components.md @@ -0,0 +1,117 @@ +--- +reviewers: +- raelga +title: Componentes de Kubernetes +content_type: concept +weight: 20 +card: + name: concepts + weight: 20 +--- + + + +Este documento describe los distintos componentes que +son necesarios para operar un clúster de Kubernetes. + + + +## Componentes del plano de control + +Los componentes que forman el plano de control toman decisiones globales sobre +el clúster (por ejemplo, la planificación) y detectan y responden a eventos del clúster, como la creación +de un nuevo pod cuando la propiedad `replicas` de un controlador de replicación no se cumple. + +Estos componentes pueden ejecutarse en cualquier nodo del clúster. Sin embargo para simplificar, los +scripts de instalación típicamente se inician en el mismo nodo de forma exclusiva, +sin que se ejecuten contenedores de los usuarios en esos nodos. El plano de control se ejecuta en varios nodos +para garantizar la [alta disponibilidad](/docs/admin/high-availability/). + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +Estos controladores incluyen: + + * Controlador de nodos: es el responsable de detectar y responder cuándo un nodo deja de funcionar + * Controlador de replicación: es el responsable de mantener el número correcto de pods para cada controlador + de replicación del sistema + * Controlador de endpoints: construye el objeto `Endpoints`, es decir, hace una unión entre los `Services` y los `Pods` + * Controladores de tokens y cuentas de servicio: crean cuentas y tokens de acceso a la API por defecto para los nuevos {{< glossary_tooltip text="Namespaces" term_id="namespace">}}. + +### cloud-controller-manager + +[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) ejecuta controladores que +interactúan con proveedores de la nube. El binario `cloud-controller-manager` es una característica alpha que se introdujo en la versión 1.6 de Kubernetes. + +`cloud-controller-manager` sólo ejecuta ciclos de control específicos para cada proveedor de la nube. Es posible +desactivar estos ciclos en `kube-controller-manager` pasando la opción `--cloud-provider= external` cuando se arranque el `kube-controller-manager`. + +`cloud-controller-manager` permite que el código de Kubernetes y el del proveedor de la nube evolucionen de manera independiente. Anteriormente, el código de Kubernetes dependía de la funcionalidad específica de cada proveedor de la nube. En el futuro, el código que sea específico a una plataforma debería ser mantenido por el proveedor de la nube y enlazado a `cloud-controller-manager` al correr Kubernetes. + +Los siguientes controladores dependen de alguna forma de un proveedor de la nube: + + * Controlador de nodos: es el responsable de detectar y actuar cuándo un nodo deja de responder + * Controlador de rutas: para configurar rutas en la infraestructura de nube subyacente + * Controlador de servicios: para crear, actualizar y eliminar balanceadores de carga en la nube + * Controlador de volúmenes: para crear, conectar y montar volúmenes e interactuar con el proveedor de la nube para orquestarlos + +## Componentes de nodo + +Los componentes de nodo corren en cada nodo, manteniendo a los pods en funcionamiento y proporcionando el entorno de ejecución de Kubernetes. + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +[kube-proxy](/docs/admin/kube-proxy/) permite abstraer un servicio en Kubernetes manteniendo las +reglas de red en el anfitrión y haciendo reenvío de conexiones. + +### Runtime de contenedores + +El {{< glossary_definition term_id="container-runtime" text="runtime de los contenedores" >}} es el software responsable de ejecutar los contenedores. Kubernetes soporta varios de +ellos: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) y cualquier implementación de la interfaz de runtime de contenedores de Kubernetes, o [Kubernetes CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). + +## Addons + +Los _addons_ son pods y servicios que implementan funcionalidades del clúster. Estos pueden ser administrados +por `Deployments`, `ReplicationControllers` y otros. Los _addons_ asignados a un espacio de nombres se crean en el espacio `kube-system`. + +Más abajo se describen algunos _addons_. Para una lista más completa de los _addons_ disponibles, por favor visite [Addons](/docs/concepts/cluster-administration/addons/). + +### DNS + +Si bien los otros _addons_ no son estrictamente necesarios, todos los clústers de Kubernetes deberían tener un [DNS interno del clúster](/docs/concepts/services-networking/dns-pod-service/) ya que la mayoría de los ejemplos lo requieren. + +El DNS interno del clúster es un servidor DNS, adicional a los que ya podrías tener en tu red, que sirve registros DNS a los servicios de Kubernetes. + +Los contenedores que son iniciados por Kubernetes incluyen automáticamente este servidor en sus búsquedas DNS. + +### Interfaz Web (Dashboard) {#dashboard} + +El [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) es una interfaz Web de propósito general para clústeres de Kubernetes. Le permite a los usuarios administrar y resolver problemas que puedan presentar tanto las aplicaciones como el clúster. + +### Monitor de recursos de contenedores + +El [Monitor de recursos de contenedores](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) almacena +de forma centralizada series de tiempo con métricas sobre los contenedores, y provee una interfaz para navegar estos +datos. + +### Registros del clúster + +El mecanismo de [registros del clúster](/docs/concepts/cluster-administration/logging/) está a cargo de almacenar +los registros de los contenedores de forma centralizada, proporcionando una interfaz de búsqueda y navegación. diff --git a/content/es/docs/reference/glossary/controller.md b/content/es/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..8258d0ae86 --- /dev/null +++ b/content/es/docs/reference/glossary/controller.md @@ -0,0 +1,33 @@ +--- +title: Controlador +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Los controladores son bucles de control que observan el estado del clúster, + y ejecutan o solicitan los cambios que sean necesarios para alcanzar el estado + deseado. + +aka: +tags: +- architecture +- fundamental +--- + +En Kubernetes, los controladores son bucles de control que observan el estado del +{{< glossary_tooltip term_id="cluster" text="clúster">}}, y ejecutan o solicitan +los cambios que sean necesarios para llevar el estado actual del clúster más +cerca del estado deseado. + + + +Los controladores observan el estado compartido del clúster a través del +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} (parte del +{{< glossary_tooltip term_id="control-plane" text="plano de control" >}}). + +Algunos controladores también se ejecutan dentro del mismo plano de control, +proporcionado los bucles de control necesarios para las operaciones principales +de Kubernetes. Por ejemplo, el controlador de Deployments, el controlador de +DaemonSets, el controlador de Namespaces y el controlador de volúmenes +persistentes, entre otros, se ejecutan dentro del +{{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/es/docs/reference/glossary/etcd.md b/content/es/docs/reference/glossary/etcd.md new file mode 100755 index 0000000000..5ac470a85c --- /dev/null +++ b/content/es/docs/reference/glossary/etcd.md @@ -0,0 +1,24 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + Almacén de datos persistente, consistente y distribuido de clave-valor utilizado + para almacenar toda a la información del clúster de Kubernetes. + +aka: +tags: +- architecture +- storage +--- + +Almacén de datos persistente, consistente y distribuido de clave-valor utilizado +para almacenar toda a la información del clúster de Kubernetes. + + + +Si tu clúster utiliza etcd como sistema de almacenamiento, échale un vistazo a la +documentación sobre [estrategias de backup](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster). + +Puedes encontrar información detallada sobre etcd en su [documentación oficial](https://etcd.io/docs/). diff --git a/content/es/docs/reference/glossary/kube-apiserver.md b/content/es/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..3363f3edcb --- /dev/null +++ b/content/es/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,26 @@ +--- +title: API Server +id: kube-apiserver +date: 2020-07-01 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + Componente del plano de control que expone la API de Kubernetes. + +aka: +- Servidor de la API +- kube-apiserver +tags: +- architecture +- fundamental +--- + +El servidor de la API es el componente del {{< glossary_tooltip text="plano de control" term_id="control-plane" >}} +de Kubernetes que expone la API de Kubernetes. Se trata del frontend de Kubernetes, +recibe las peticiones y actualiza acordemente el estado en {{< glossary_tooltip term_id="etcd" length="all" >}}. + + + +La principal implementación de un servidor de la API de Kubernetes es +[kube-apiserver](/docs/reference/generated/kube-apiserver/). +Es una implementación preparada para ejecutarse en alta disponiblidad y que +puede escalar horizontalmente para balancear la carga entre varias instancias. \ No newline at end of file diff --git a/content/es/docs/reference/glossary/kube-controller-manager.md b/content/es/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..4a9bd20877 --- /dev/null +++ b/content/es/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,21 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ +short_description: > + Componente del plano de control que ejecuta los controladores de Kubernetes. + +aka: +tags: +- architecture +- fundamental +--- + +Componente del plano de control que ejecuta los {{< glossary_tooltip text="controladores" term_id="controller" >}} de Kubernetes. + + + +Lógicamente cada {{< glossary_tooltip text="controlador" term_id="controller" >}} +es un proceso independiente, pero para reducir la complejidad, todos se compilan +en un único binario y se ejecuta en un mismo proceso. diff --git a/content/es/docs/reference/glossary/kube-scheduler.md b/content/es/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..ea7914495a --- /dev/null +++ b/content/es/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,25 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + Componente del plano de control que está pendiente de los pods que no tienen + ningún nodo asignado y seleciona uno dónde ejecutarlo. + +aka: +tags: +- architecture +--- + +Componente del plano de control que está pendiente de los +{{< glossary_tooltip term_id="pod" text="Pods" >}} que no tienen ningún +{{< glossary_tooltip term_id="node" text="nodo">}} asignado +y seleciona uno donde ejecutarlo. + + + +Para decidir en qué {{< glossary_tooltip term_id="node" text="nodo">}} +se ejecutará el {{< glossary_tooltip term_id="pod" text="pod" >}}, se tienen +en cuenta diversos factores: requisitos de recursos, restricciones de hardware/software/políticas, +afinidad y anti-afinidad, localización de datos dependientes, entre otros. diff --git a/content/es/docs/reference/glossary/namespace.md b/content/es/docs/reference/glossary/namespace.md new file mode 100755 index 0000000000..4ceec4db73 --- /dev/null +++ b/content/es/docs/reference/glossary/namespace.md @@ -0,0 +1,22 @@ +--- +title: Namespace +id: namespace +date: 2018-04-12 +full_link: /es/docs/concepts/overview/working-with-objects/namespaces/ +short_description: > + Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico. +aka: +- Espacio de nombres +tags: +- fundamental +--- + +Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales +en el mismo {{< glossary_tooltip text="clúster" term_id="cluster" >}} físico. + + + +Los Namespaces, espacios de nombres, se utilizan para organizar objetos del clúster +proporcionando un mecanismo para dividir los recusos del clúster. Los nombres de los +objetos tienen que ser únicos dentro del mismo namespace, pero se pueden repetir en +otros namespaces del mismo clúster. \ No newline at end of file From 65c689476938cb2f82b6aa259c641cbfce3476c5 Mon Sep 17 00:00:00 2001 From: inductor Date: Tue, 7 Jul 2020 22:45:38 +0900 Subject: [PATCH 33/99] localize localization --- content/ja/docs/contribute/localization.md | 312 ++++++--------------- 1 file changed, 93 insertions(+), 219 deletions(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index c9b1221b53..ddbeddcbc9 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -9,272 +9,146 @@ card: -このページでは、ドキュメントを異なる言語に[翻訳](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)する方法について紹介します。 +このページでは、Kubernetesドキュメントにおける日本語翻訳の方針について説明します。 -## はじめる +## ドキュメントを日本語に翻訳するまでの流れ -コントリビューターが自分自身のプルリクエストを承認することはできないため、翻訳を始めるには、最低でも2人が必要です。 +翻訳を行うための基本的な流れについて説明します。不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてご連絡ください。 -すべての翻訳チームは、自分たちのリソースを継続的に自己管理しなければいけません。私たちはドキュメントを喜んでホストしますが、あなたの代わりに翻訳することはできないからです。 +### 前提知識 -### 2文字の言語コードを探す +翻訳作業は全て[GitHubのIssue](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+label%3Alanguage%2Fja)によって管理されています。翻訳作業を行いたい場合は、Issueの一覧をまず最初にご確認ください。 -最初に、[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)のドキュメントから、翻訳先の言語に対応する2文字の国コードを探してください。たとえば、韓国語の国コードは`ko`です。 +また、Kubernetes傘下のリポジトリでは`CLA`と呼ばれる同意書に署名されたGitHubユーザーのみがパッチを送ることができます。詳しくは[英語のドキュメント](https://github.com/kubernetes/community/blob/master/CLA.md)や、[Qiitaに有志の方が書いてくださった日本語のまとめ](https://qiita.com/jlandowner/items/d14d9bc8797a62b65e67)をご覧ください。 -### リポジトリをフォーク・クローンする {#fork-and-clone-the-repo} +### 翻訳を始めるまで -初めに、[kubernetes/website](https://github.com/kubernetes/website)リポジトリの[自分用のフォークを作成](/docs/contribute/start/#improve-existing-content)します。 +#### 翻訳を希望するページのIssueが存在しない場合 -そして、フォークをクローンして、ディレクトリに`cd`します。 +1. [こちらのサンプル](https://github.com/kubernetes/website/issues/22340)に従う形でIssueを作成する +2. 自分自身を翻訳作業に割り当てたい場合は、Issueのメッセージまたはコメントに`/assign`と書く +3. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -```shell -git clone https://github.com//website -cd website -``` +**分からないことがあれば上記Slackチャンネルまでご質問をお願いします。** -### プルリクエストを開く +#### 翻訳を希望するページのIssueが存在した場合 -次に、`kubernetes/website`リポジトリに翻訳を追加するための[プルリクエスト(PR)を開きます](/docs/contribute/start/#submit-a-pull-request)。 +1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに`/assign`と書く +2. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -このPRが承認されるためには、[最低限必要なコンテンツ](#minimum-required-content)が含まれていなければなりません。 +### パッチを送るまで -新しい翻訳を追加する例としては、[フランス語版ドキュメントを追加するPR](https://github.com/kubernetes/website/pull/12548)を参考にしてください。 +実際に翻訳作業を行う場合、未翻訳ページの新規作成と既存ページの修正でそれぞれ手順が異なります。 -### Kubernetes GitHub organizationに参加する +既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。 -翻訳のPRを作ると、Kubernetes GitHub organizationのメンバーになることができます。チームの各個人は、それぞれ`kubernetes/org`リポジトリに[Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose)を作成する必要があります。 +#### 新規ページを翻訳する場合 {#translate-new-page} -### 翻訳チームをGitHubに追加する {#add-your-localization-team-in-github} +1. `kubernetes/website`リポジトリをフォークする +2. `master`から任意の名前でブランチを作成し、翻訳する箇所を編集する +3. `master`ブランチに向けてPull Requestを作成する -次に、Kubernetesの翻訳チームを[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)に追加します。翻訳チームを追加する例として、[スペイン語の翻訳チーム](https://github.com/kubernetes/org/pull/685)を追加するPRを見てください。 +#### 既存のページの誤字脱字や古い記述を修正する場合 -`@kubernetes/sig-docs-**-owners`のメンバーは、翻訳のディレクトリ`/content/**/`以下のコンテンツのみを変更するPRを承認できます。 +1. `kubernetes/website`リポジトリをフォークする +2. `dev-1.17-ja.3(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する +3. `dev-1.17-ja.3(最新のマイルストーンブランチに適宜読み替えること)`ブランチに向けてPull Requestを作成する -各翻訳ごとに、新しいPRに対して`@kubernetes/sig-docs-**-reviews`チームがレビューに自動的にアサインされます。 +- masterを追随 + - 更新があり次第、次のMilestoneで追随を行う +- コントリビューション方法については[こちら](https://kubernetes-docs-ja.kibe.la/shared/entries/c5878aa5-ad1f-4f29-a5bb-25853cbc14ec)を参照 +- 翻訳スタイルガイドについては[こちら](https://kubernetes-docs-ja.kibe.la/shared/entries/5efe4fa7-d2a1-4a1d-8bc3-ce7ccdc064a6)を参照 -`@kubernetes/website-maintainers`のメンバーは、翻訳作業を調整するために新しい開発ブランチを作ることができます。 +### マイルストーンについて {#milestones} -`@kubernetes/website-milestone-maintainers`のメンバーは、issueやPRにマイルストーンをアサインするために、`/milestone`[Prowコマンド](https://prow.k8s.io/command-help)が使用できます。 +翻訳作業を集中的に管理するために、日本語を含む複数の言語ではマイルストーンを採用しています。 -### ワークフローを設定する {#configure-the-workflow} +各マイルストーンでは、 -次に、`kubernetes/test-infra`リポジトリに新しい翻訳用のGitHubラベルを追加します。ラベルを利用すると、issueやプルリクエストを特定の言語のものだけにフィルタできます。 +- 最低要件のコンテンツの追加・更新(項目については[こちら](https://kubernetes.io/docs/contribute/localization/#translating-documents)) +- バージョンに追従できていない翻訳済みコンテンツの更新 -ラベルを追加する例としては、[イタリア語の言語ラベル](https://github.com/kubernetes/test-infra/pull/11316)を追加するPRを見てください。 +を行い、ドキュメントの全体的なメンテナンスを行っています。 -### コミュニティを見つける +マイルストーンのバージョンはOwner権限を持つメンバーが管理するものとします。 -Kubernetes SIG Docsに、新しく翻訳チームを作りたいという意思を知らせてください！[SIG Docs Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加してください。他の言語のメンバーが、翻訳を始めるのを喜んで助けてくれ、どんな疑問にも答えてくれます。 +## 翻訳スタイルガイド -`kubernetes/community`リポジトリ内で、翻訳用のSlackチャンネルを作ることもできます。Slackチャンネルを追加する例としては、[インドネシア語とポルトガル語用のチャンネルを追加する](https://github.com/kubernetes/community/pull/3605)ためのPRを見てください。 +### 基本方針 -## 最低限必要なコンテンツ {#minimum-required-content} +- 本文を、敬体（ですます調）で統一 + - 特に、「〜になります」「〜となります」という表現は「〜です」の方が適切な場合が多いため注意 +- 句読点は「、」と「。」を使用 +- 漢字、ひらがな、カタカナは全角で表記 +- 数字とアルファベットは半角で表記 +- スペースと括弧 `()` 、コロン `:` は半角、それ以外の記号類は全角で表記 +- 英単語と日本語の間に半角スペースは不要 -### サイトの設定を修正する +### 頻出単語 -Kubernetesのウェブサイトでは、Hugoをウェブフレームワークとして使用しています。ウェブサイトのHugoの設定は、[`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml)ファイルの中に書かれています。新しい翻訳をサポートするには、`config.toml`を修正する必要があります。 +英語 | 日本語 +--------- | --------- +cluster|クラスター +orchestrate(動詞)|オーケストレーションする +Persistent Volume|KubernetesリソースとしてのPersistentVolumeはママ表記、一般的な用語としての場合は、永続ボリューム +Deployment/Deploy|KubernetesリソースとしてのDeploymentはママ表記、一般的な用語としてのdeployの場合は、デプロイ +Addon/Add-on|アドオン +Quota|クォータ +For more information|さらなる情報(一時的) +prefix | プレフィックス +container | コンテナ +directory | ディレクトリ +binary | バイナリ +controller | コントローラー +opeartor | オペレーター +Aggregation Layer | アグリゲーションレイヤー +Issue | Issue (ママ表記) +Pull Request | Pull Request (ママ表記) +GitHub | GitHub (ママ表記) +registry | レジストリ +architecture | アーキテクチャ +secure | セキュア -`config.toml`の既存の`[languages]`ブロックの下に、新しい言語の設定ブロックを追加してください。たとえば、ドイツ語のブロックの場合、次のようになります。 +### 備考 -```toml -[languages.de] -title = "Kubernetes" -description = "Produktionsreife Container-Verwaltung" -languageName = "Deutsch" -contentDir = "content/de" -weight = 3 -``` +ServiceやDeploymentなどのKubernetesのAPIオブジェクトや技術仕様的な固有名詞は、無理に日本語訳せずそのまま書いてください。日本語では複数形にする意味はあまりないので、原則として単数形に統一します。 -ブロックの`weight`パラメーターの設定では、言語の一覧から最も数字の大きい番号を探し、その値に1を加えた値を指定してください。 +- Kubernetes Service +- Node +- Pod -Hugoの多言語サポートについての詳しい情報は、「[多言語モード](https://gohugo.io/content-management/multilingual/)」を参照してください。 +外部サイトへの参照の記事タイトルは翻訳しましょう。(一時的) -### 新しい翻訳のディレクトリを追加する +### 頻出表記（日本語） -[`content`](https://github.com/kubernetes/website/tree/master/content)フォルダーに、言語用のサブディレクトリを追加してください。2文字の言語コードが`de`であるドイツ語の場合、次のようにディレクトリを作ります。 +よくある表記 | あるべき形 +--------- | --------- +〜ので、〜から、〜だから| 〜のため 、〜ため +（あいうえお。）| （あいうえお）。 +〇,〇,〇|〇、〇、〇（※今回列挙はすべて読点で統一） -```shell -mkdir content/de -``` +### 単語末尾に長音記号(「ー」)を付けるかどうか -### Community Code of Conductを翻訳する +「サーバー」「ユーザー」など英単語をカタカナに訳すときに、末尾の「ー」を付けるかどうか。 -あなたの言語のcode of conductを追加するために、PRを[`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages)リポジトリに対して開いてください。 +- 「r」「re」「y」などで終わる単語については、原則付ける +- 上の頻出語のように、別途まとめたものは例外とする -### 翻訳したREADMEを追加する +参考: https://kubernetes.slack.com/archives/CAG2M83S8/p1554096635015200 辺りのやりとり -他の翻訳のコントリビューターをガイドするために、kubernetes/websiteのトップレベルに新しい[`README-**.md`](https://help.github.com/articles/about-readmes/)を追加してください。ここで、`**`は2文字の言語コードです。たとえば、ドイツ語のREADMEファイルは`README-de.md`です。 +### cron jobの訳し方に関して -翻訳された`README-**.md`ファイルの中で、翻訳のコントリビューターにガイダンスを提供してください。`README.md`に含まれているのと同じ情報に加えて、以下の情報も追加してください。 +混同を避けるため、cron jobはcronジョブと訳し、CronJobはリソース名としてのままにする。 +cron「の」ジョブは、「の」が続く事による解釈の難から基本的にはつけないものとする。 -- 翻訳プロジェクトのための連絡先 -- 翻訳固有の情報 +### その他基本方針など -翻訳されたREADMEを作成したら、メインの英語の`README.md`からそのファイルへのリンクを追加し、英語で連絡先情報も書いてください。GitHub ID、メールアドレス、[Slackチャンネル](https://slack.com)、その他の連絡手段を提供できます。翻訳されたCommunity Code of Conductへのリンクも必ず提供してください。 - -### OWNERSファイルを設定する - -翻訳にコントリビュートする各ユーザーのロールを設定するには、言語用のサブディレクトリの中に`OWNERS`ファイルを作成し、以下の項目を設定します。 - -- **レビュアー**: レビュアーのロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で作成した`sig-docs-**-reviews`チームです。 -- **承認者**: 承認者のロールを持つkubernetesチームのリストです。この場合は、[GitHubで翻訳チームを追加](#add-your-localization-team-in-github)で追加した`sig-docs-**-owners`チームです。 -- **ラベル**: PRに自動的に適用されるGitHub上のラベルのリストです。この場合は、[ワークフローを設定する](#configure-the-workflow)で作成した言語ラベルです。 - -`OWNERS`ファイルに関するより詳しい情報は、[go.k8s.io/owners](https://go.k8s.io/owners)を参照してください。 - -言語コードが`es`の[スペイン語のOWNERSファイル](https://git.k8s.io/website/content/es/OWNERS)は次のようになります。 - -```yaml -# See the OWNERS docs at https://go.k8s.io/owners - -# This is the localization project for Spanish. -# Teams and members are visible at https://github.com/orgs/kubernetes/teams. - -reviewers: -- sig-docs-es-reviews - -approvers: -- sig-docs-es-owners - -labels: -- language/es -``` - -特定の言語用の`OWNERS`ファイルを追加したら、[ルートの`OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES)ファイルを、翻訳のための新しいKuerbetesチーム、`sig-docs-**-owners`および`sig-docs-**-reviews`で更新します。 - -各チームごとに、[翻訳チームをGitHubに追加する](#add-your-localization-team-in-github)でリクエストしたGitHubユーザーのリストをアルファベット順で追加してください。 - -```diff ---- a/OWNERS_ALIASES -+++ b/OWNERS_ALIASES -@@ -48,6 +48,14 @@ aliases: - - stewart-yu - - xiangpengzhao - - zhangxiaoyu-zidif -+ sig-docs-es-owners: # Admins for Spanish content -+ - alexbrand -+ - raelga -+ sig-docs-es-reviews: # PR reviews for Spanish content -+ - alexbrand -+ - electrocucaracha -+ - glo-pena -+ - raelga - sig-docs-fr-owners: # Admins for French content - - perriea - - remyleone -``` - -## コンテンツを翻訳する - -Kubernetesのドキュメントの *すべて* を翻訳するのは、非常に大きな作業です。小さく始めて、時間をかけて拡大していけば大丈夫です。 - -最低限、すべての翻訳には以下のコンテンツが必要です。 - -説明 | URL ------|----- -ホーム | [すべての見出しと小見出しのURL](/docs/home/) -セットアップ | [すべての見出しと小見出しのURL](/docs/setup/) -チュートリアル | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)、[Hello Minikube](/docs/tutorials/hello-minikube/) -サイト文字列 | [翻訳された新しいTOMLファイル内のすべてのサイト文字列](https://github.com/kubernetes/website/tree/master/i18n) - -翻訳されたドキュメントは、言語ごとに`content/**/`サブディレクトリに置き、英語のソースと同じURLパスに従うようにしなければいけません。たとえば、[Kubernetes Basics](/docs/tutorials/kubernetes-basics/)のチュートリアルをドイツ語に翻訳する準備をするには、次のように、`content/de/`フォルダ以下にサブディレクトリを作り、英語のソースをコピーします。 - -```shell -mkdir -p content/de/docs/tutorials -cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md -``` - -翻訳ツールを使えば、翻訳のプロセスをスピードアップできます。たとえば、エディタによってはテキストを高速に翻訳してくれるプラグインがあります。 - -{{< caution >}} -機械生成された翻訳は、そのままでは最低限の品質基準を満たしません。基準を満たすためには、人間による十分なレビューが必要です。 -{{< /caution >}} - -文法と意味の正確さを保証するために、公開する前に翻訳チームのメンバーが機械生成されたすべての翻訳を注意深くレビューしなければいけません。 - -### ソースファイル - -翻訳は、最新のリリース{{< latest-version >}}の英語のファイルをベースにしなければなりません。 - -最新のリリースのソースファイルを見つけるには、次のように探してください。 - -1. Kubernetesのウェブサイトのリポジトリ https://github.com/kubernetes/website に移動する。 -2. 最新バージョンの`release-1.X`ブランチを選択する。 - -最新バージョンは{{< latest-version >}}であるため、最新のリリースブランチは[`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}})です。 - -### i18n/内のサイト文字列 - -翻訳には、[`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml)の内容を新しい言語用のファイル内に含める必要があります。ドイツ語を例に取ると、ファイル名は`i18n/de.toml`です。 - -新しい翻訳ファイルを`i18n/`に追加します。たとえば、ドイツ語(`de`)であれば次のようになります。 - -```shell -cp i18n/en.toml i18n/de.toml -``` - -そして、各文字列の値を翻訳します。 - -```TOML -[docs_label_i_am] -other = "ICH BIN..." -``` - -サイト文字列を翻訳することで、サイト全体で使われるテキストや機能をカスタマイズできます。たとえば、各ページのフッターにある著作権のテキストなどです。 - -### 言語固有のスタイルガイドと用語集 - -一部の言語チームには、言語固有のスタイルガイドや用語集があります。たとえば、[韓国語の翻訳ガイド](/ko/docs/contribute/localization_ko/)を見てください。 - -## ブランチの戦略 - -翻訳プロジェクトは協力が非常に重要な活動のため、チームごとに共有の開発ブランチで作業することを推奨します。 - -開発ブランチ上で共同作業するためには、以下の手順を行います。 - -1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers)のチームメンバーが https://github.com/kubernetes/website のソースブランチから開発ブランチを作る。 - - [`kubernetes/org`](https://github.com/kubernetes/org)リポジトリに[翻訳チームを追加](#add-your-localization-team-in-github)したとき、チームの承認者は`@kubernetes/website-maintainers`チームに参加します。 - - 次のようなブランチの命名規則に従うことを推奨します。 - - `dev-<ソースのバージョン>-<言語コード>.<チームのマイルストーン>` - - たとえば、ドイツ語の翻訳チームの承認者は、Kubernetes v1.12のソースブランチをベースに、k/websiteリポジトリから直接開発ブランチ`dev-1.12-de.1`を作ります。 - -2. 各コントリビューターが、開発ブランチをベースにフィーチャーブランチを作る。 - - たとえば、ドイツ語のコントリビューターは、`username:local-branch-name`から`kubernetes:dev-1.12-de.1`に対して、変更を含むプルリクエストを開きます。 - -3. 承認者がフィーチャーブランチをレビューして、開発ブランチにマージする。 - -4. 定期的に新しいプルリクエストを開いて承認することで、承認者が開発ブランチをソースブランチにマージする。プルリクエストを承認する前にコミットをsquashするようにしてください。 - -翻訳が完了するまで、1-4のステップを必要なだけ繰り返します。たとえば、ドイツ語のブランチは、`dev-1.12-de.2`、`dev-1.12-de.3`と続きます。 - -チームは、翻訳したコンテンツを元となったリリースブランチにマージする必要があります。たとえば、{{< release-branch >}}から作られた開発ブランチは、必ず{{< release-branch >}}にマージしなければなりません。 - -承認者は、ソースブランチを最新の状態に保ち、マージのコンフリクトを解決することで、開発ブランチをメンテナンスしなければなりません。開発ブランチが長く開いたままであるほど、一般により多くのメンテナンスが必要になります。そのため、非常に長い期間に渡って開発ブランチを維持するよりは、定期的に開発ブランチをマージして、新しいブランチを作ることを考えてください。 - -各チームマイルストーンの最初には、1つ前の開発ブランチと現在の開発ブランチの間のアップストリームの変更を比較するissueを開くと役に立ちます。 - -新しい開発ブランチを開いたりプルリクエストをマージできるのは承認者だけですが、新しい開発ブランチには誰でもプルリクエストを開くことができます。特別な許可は必要ありません。 - -フォークやリポジトリから直接行う作業についての詳しい情報は、「[リポジトリをフォーク・クローンする](#fork-and-clone-the-repo)」を読んでください。 +- 意訳と直訳で迷った場合は「直訳」で訳す +- 訳で難しい・わからないと感じたらSlackの#kubernetes-docs-jaでみんなに聞く +- できることを挙手制で、できないときは早めに報告 ## アップストリームのコントリビューター SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/docs/contribute/intermediate#localize-content)を歓迎しています。 - -## 既存の翻訳を助ける - -コンテンツの追加や改善により既存の翻訳を助けることもできます。翻訳のための[Slackチャンネル](https://kubernetes.slack.com/messages/C1J0BPD2M/)に参加して、助けとなるPRを開くことを始めましょう。 - -## {{% heading "whatsnext" %}} - -翻訳がワークフローと最小限のコンテンツの要件を満たしたら、SIG docsは次の作業を行います。 - -- ウェブサイト上で言語の選択を有効にする。 -- [Kubernetesブログ](https://kubernetes.io/blog/)を含む[Cloud Native Computing Foundation](https://www.cncf.io/about/)(CNCF)のチャンネルで、翻訳が利用できるようになったことを公表する。 From 546fca36424cbe927b79de830d2ea9831f28c603 Mon Sep 17 00:00:00 2001 From: inductor Date: Tue, 7 Jul 2020 22:46:41 +0900 Subject: [PATCH 34/99] update version --- content/ja/docs/contribute/localization.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index ddbeddcbc9..5cdc87948f 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -53,8 +53,8 @@ card: #### 既存のページの誤字脱字や古い記述を修正する場合 1. `kubernetes/website`リポジトリをフォークする -2. `dev-1.17-ja.3(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する -3. `dev-1.17-ja.3(最新のマイルストーンブランチに適宜読み替えること)`ブランチに向けてPull Requestを作成する +2. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する +3. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`ブランチに向けてPull Requestを作成する - masterを追随 - 更新があり次第、次のMilestoneで追随を行う From c2416098102f3c460254d358cdfb8a913153c40e Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:38:38 +0900 Subject: [PATCH 35/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index 5cdc87948f..14d8997d85 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -33,7 +33,7 @@ card: **分からないことがあれば上記Slackチャンネルまでご質問をお願いします。** -#### 翻訳を希望するページのIssueが存在した場合 +#### 翻訳を希望するページのIssueが存在する場合 1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに`/assign`と書く 2. [新規ページを翻訳する場合](#translate-new-page)のステップに進む From a677e2f3cf795339b67cb88a3f3804eeb924b55c Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:38:45 +0900 Subject: [PATCH 36/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index 14d8997d85..ce9e16c0d6 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -38,7 +38,7 @@ card: 1. 自分自身を翻訳作業に割り当てるために、Issueのコメントに`/assign`と書く 2. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -### パッチを送るまで +### Pull Requestを送るまで 実際に翻訳作業を行う場合、未翻訳ページの新規作成と既存ページの修正でそれぞれ手順が異なります。 From bfe6a49359e3a90e1371e8d53a0e08ea6cb2e766 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:39:03 +0900 Subject: [PATCH 37/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index ce9e16c0d6..8f926c220a 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -67,7 +67,7 @@ card: 各マイルストーンでは、 -- 最低要件のコンテンツの追加・更新(項目については[こちら](https://kubernetes.io/docs/contribute/localization/#translating-documents)) +- 最低要件のコンテンツの追加・更新(項目については[こちら](https://kubernetes.io/docs/contribute/localization/#translating-documents)を参照してください) - バージョンに追従できていない翻訳済みコンテンツの更新 を行い、ドキュメントの全体的なメンテナンスを行っています。 From 7e4093bd06c4c93cf2f5b2c7fa1049f6326d0141 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:39:17 +0900 Subject: [PATCH 38/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index 8f926c220a..c078094bf4 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -40,7 +40,7 @@ card: ### Pull Requestを送るまで -実際に翻訳作業を行う場合、未翻訳ページの新規作成と既存ページの修正でそれぞれ手順が異なります。 +未翻訳ページの新規翻訳作業と既存ページの修正作業でそれぞれ手順が異なります。 既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。 From 34dbe1840491a1a11c4fa3ec1c51cc32b0af9404 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:39:27 +0900 Subject: [PATCH 39/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index c078094bf4..a75e74875f 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -50,7 +50,7 @@ card: 2. `master`から任意の名前でブランチを作成し、翻訳する箇所を編集する 3. `master`ブランチに向けてPull Requestを作成する -#### 既存のページの誤字脱字や古い記述を修正する場合 +#### 既存のページの誤字脱字や古い記述を修正する場合の手順 1. `kubernetes/website`リポジトリをフォークする 2. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する From da5b6d719dec6de6a8260333fb4c3ceaea488e40 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:39:43 +0900 Subject: [PATCH 40/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index a75e74875f..f723d743e9 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -54,7 +54,7 @@ card: 1. `kubernetes/website`リポジトリをフォークする 2. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する -3. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`ブランチに向けてPull Requestを作成する +3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する - masterを追随 - 更新があり次第、次のMilestoneで追随を行う From addcdd9df97dcb1111f93102491e95579a02367f Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:39:56 +0900 Subject: [PATCH 41/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index f723d743e9..4a7f80945c 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -44,7 +44,7 @@ card: 既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。 -#### 新規ページを翻訳する場合 {#translate-new-page} +#### 新規ページを翻訳する場合の手順 {#translate-new-page} 1. `kubernetes/website`リポジトリをフォークする 2. `master`から任意の名前でブランチを作成し、翻訳する箇所を編集する From 51e9f78c271869410ff8b3f29944cb05d0cc38aa Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 9 Jul 2020 16:40:10 +0900 Subject: [PATCH 42/99] Update content/ja/docs/contribute/localization.md Co-authored-by: nasa9084 --- content/ja/docs/contribute/localization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index 4a7f80945c..fd39c679d2 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -53,7 +53,7 @@ card: #### 既存のページの誤字脱字や古い記述を修正する場合の手順 1. `kubernetes/website`リポジトリをフォークする -2. `dev-1.18-ja.1(最新のマイルストーンブランチに適宜読み替えること)`から任意の名前でブランチを作成し、該当箇所を編集する +2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する 3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する - masterを追随 From 33f2e430ca8fc435934133512f0a86fff5280939 Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 9 Jul 2020 16:49:58 +0900 Subject: [PATCH 43/99] apply review --- content/ja/docs/contribute/localization.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index fd39c679d2..4ae915630b 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -47,8 +47,9 @@ card: #### 新規ページを翻訳する場合の手順 {#translate-new-page} 1. `kubernetes/website`リポジトリをフォークする -2. `master`から任意の名前でブランチを作成し、翻訳する箇所を編集する -3. `master`ブランチに向けてPull Requestを作成する +2. `master`から任意の名前でブランチを作成する +3. `content/en`のディレクトリから必要なファイルを`content/ja`にコピーし、翻訳する +4. `master`ブランチに向けてPull Requestを作成する #### 既存のページの誤字脱字や古い記述を修正する場合の手順 @@ -56,11 +57,6 @@ card: 2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する 3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する -- masterを追随 - - 更新があり次第、次のMilestoneで追随を行う -- コントリビューション方法については[こちら](https://kubernetes-docs-ja.kibe.la/shared/entries/c5878aa5-ad1f-4f29-a5bb-25853cbc14ec)を参照 -- 翻訳スタイルガイドについては[こちら](https://kubernetes-docs-ja.kibe.la/shared/entries/5efe4fa7-d2a1-4a1d-8bc3-ce7ccdc064a6)を参照 - ### マイルストーンについて {#milestones} 翻訳作業を集中的に管理するために、日本語を含む複数の言語ではマイルストーンを採用しています。 @@ -113,7 +109,11 @@ secure | セキュア ### 備考 -ServiceやDeploymentなどのKubernetesのAPIオブジェクトや技術仕様的な固有名詞は、無理に日本語訳せずそのまま書いてください。日本語では複数形にする意味はあまりないので、原則として単数形に統一します。 +ServiceやDeploymentなどのKubernetesのAPIオブジェクトや技術仕様的な固有名詞は、無理に日本語訳せずそのまま書いてください。 + +また、日本語では名詞を複数形にする意味はあまりないので、英語の名詞を利用する場合は原則として単数形で表現してください。 + +例: - Kubernetes Service - Node From 80b31db370641522514fe726a681617ed36171f7 Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 9 Jul 2020 16:52:36 +0900 Subject: [PATCH 44/99] fix mongon --- content/ja/docs/contribute/localization.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md index 4ae915630b..bffea11697 100644 --- a/content/ja/docs/contribute/localization.md +++ b/content/ja/docs/contribute/localization.md @@ -15,13 +15,13 @@ card: ## ドキュメントを日本語に翻訳するまでの流れ -翻訳を行うための基本的な流れについて説明します。不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてご連絡ください。 +翻訳を行うための基本的な流れについて説明します。不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。 ### 前提知識 翻訳作業は全て[GitHubのIssue](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+label%3Alanguage%2Fja)によって管理されています。翻訳作業を行いたい場合は、Issueの一覧をまず最初にご確認ください。 -また、Kubernetes傘下のリポジトリでは`CLA`と呼ばれる同意書に署名されたGitHubユーザーのみがパッチを送ることができます。詳しくは[英語のドキュメント](https://github.com/kubernetes/community/blob/master/CLA.md)や、[Qiitaに有志の方が書いてくださった日本語のまとめ](https://qiita.com/jlandowner/items/d14d9bc8797a62b65e67)をご覧ください。 +また、Kubernetes傘下のリポジトリでは`CLA`と呼ばれる同意書に署名しないと、Pull Requestをマージすることができません。詳しくは[英語のドキュメント](https://github.com/kubernetes/community/blob/master/CLA.md)や、[Qiitaに有志の方が書いてくださった日本語のまとめ](https://qiita.com/jlandowner/items/d14d9bc8797a62b65e67)をご覧ください。 ### 翻訳を始めるまで @@ -31,7 +31,7 @@ card: 2. 自分自身を翻訳作業に割り当てたい場合は、Issueのメッセージまたはコメントに`/assign`と書く 3. [新規ページを翻訳する場合](#translate-new-page)のステップに進む -**分からないことがあれば上記Slackチャンネルまでご質問をお願いします。** +**不明点がある場合は[Kubernetes公式Slack](http://slack.kubernetes.io/)の`#kubernetes-docs-ja`チャンネルにてお気軽にご質問ください。** #### 翻訳を希望するページのIssueが存在する場合 From dad5013526c2061da85c16cabed351fe8a0771c6 Mon Sep 17 00:00:00 2001 From: Irvi Firqotul Aini Date: Tue, 7 Jul 2020 15:59:31 +0700 Subject: [PATCH 45/99] docs: Translate Share Process Namespace between Containers in a Pod to ID --- .../share-process-namespace.md | 118 ++++++++++++++++++ .../pods/share-process-namespace.yaml | 17 +++ 2 files changed, 135 insertions(+) create mode 100644 content/id/docs/tasks/configure-pod-container/share-process-namespace.md create mode 100644 content/id/examples/pods/share-process-namespace.yaml diff --git a/content/id/docs/tasks/configure-pod-container/share-process-namespace.md b/content/id/docs/tasks/configure-pod-container/share-process-namespace.md new file mode 100644 index 0000000000..9b32d74b3c --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/share-process-namespace.md @@ -0,0 +1,118 @@ +--- +title: Pembagian Namespace Proses antar Container pada sebuah Pod +min-kubernetes-server-version: v1.10 +content_type: task +weight: 160 +--- + + + +{{< feature-state state="stable" for_k8s_version="v1.17" >}} + +Dokumen ini akan menjelaskan menkanisme konfigurasi pembagian namespace +process dalam sebuah Pod. Ketika pembagian _namespace_ proses diaktifkan untuk sebuah Pod, +proses yang ada di dalam Container akan bersifat transparan pada semua Container +yang terdapat di dalam Pod tersebut. + +Kamu dapat mengaktifkan fitur ini untuk melakukan konfigurasi kontainer yang saling terhubung, +misalnya saja kontainer _sidecar_ yang bertugas dalam urusan log, atau untuk melakukan +proses pemecahan masalah (_troubleshoot_) image kontainer yang tidak memiliki utilitas _debugging_ seperti shell. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Mengatur sebuah Pod + +Pembagian _namespace_ proses (_Process Namespace Sharing_) diaktifkan menggunakan _field_ `shareProcessNamespace` +`v1.PodSpec`. Sebagai contoh: + +{{< codenew file="pods/share-process-namespace.yaml" >}} + +1. Buatlah sebuah Pod `nginx` di dalam klaster kamu: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml + ``` + +2. Tempelkan kontainer `shell` dan jalankan perintah `ps`: + + ```shell + kubectl attach -it nginx -c shell + ``` + + Jika kamu tidak melihat _prompt_ perintah, kamu dapat menekan tombol enter: + + ``` + / # ps ax + PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 14 101 0:00 nginx: worker process + 15 root 0:00 sh + 21 root 0:00 ps ax + ``` + +Kamu dapat memberikan sinyal pada kontainer lain. Misalnya saja, mengirim sinyal `SIGHUP` pada +nginx untuk menjalankan ulang proses worker. Hal ini membutuhkan kapabilitas `SYS_PTRACE`. + +``` +/ # kill -HUP 8 +/ # ps ax +PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 15 root 0:00 sh + 22 101 0:00 nginx: worker process + 23 root 0:00 ps ax +``` + +Hal ini juga merupakan alasan mengapa kita dapat mengakses kontainer lain menggunakan +tautan (_link_) `/proc/$pid/root`. + +``` +/ # head /proc/8/root/etc/nginx/nginx.conf + +user nginx; +worker_processes 1; + +error_log /var/log/nginx/error.log warn; +pid /var/run/nginx.pid; + + +events { + worker_connections 1024; +``` + + + + + +## Memahami Pembagian Namespace Process + +Pod berbagi banyak sumber daya yang ada sehingga memungkinkan adanya pembagian _namespace_ +proses. Beberapa _image_ kontainer bisa jadi terisolasi dari kontainer lainnya, +meskipun begitu, memahami beberapa perbedaan berikut juga merupakan hal yang +penting untuk diketahui: + +1. **Proses kontainer tidak lagi memiliki PID 1.** Beberapa image kontainer akan menolak + untuk dijalankan (contohnya, kontainer yang menggunakan `systemd`) atau menjalankan + perintah seperti `kill -HUP 1` untuk memberikan sinyal pada proses kontainer. Di dalam Pod dengan + sebuah namespace process terbagi, sinyal `kill -HUP 1` akan diberikan pada _sandbox_ Pod. + (`/pause` pada contoh di atas.) + +2. **Proses-proses yang ada akan transparan pada kontainer lain di dalam Pod.** Hal ini termasuk + informasi pada `/proc`, seperti kata sandi yang diberikan sebagai argumen atau _environment variable_. + Hal ini hanya dilindungi oleh perizinan reguler Unix. + +3. **Berkas sistem (_filesystem_) kontainer bersifat transparan pada kontainer lain di dalam Pod melalui link + `/proc/$pid/root`.** Hal ini memungkinkan proses _debugging_ menjadi lebih mudah, meskipun begitu hal ini + juga berarti kata kunci (_secret_) yang ada di dalam _filesystem_ juga hanya dilindungi oleh perizinan _filesystem_ saja. + diff --git a/content/id/examples/pods/share-process-namespace.yaml b/content/id/examples/pods/share-process-namespace.yaml new file mode 100644 index 0000000000..af812732a2 --- /dev/null +++ b/content/id/examples/pods/share-process-namespace.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + shareProcessNamespace: true + containers: + - name: nginx + image: nginx + - name: shell + image: busybox + securityContext: + capabilities: + add: + - SYS_PTRACE + stdin: true + tty: true From aa90952bdf8545c7df242e5312d43a99d714e34d Mon Sep 17 00:00:00 2001 From: jiajie Date: Thu, 9 Jul 2020 16:22:39 +0800 Subject: [PATCH 46/99] Create 2020-03-25-kubernetes-1.18-release-announcement.md zh-trans kubernetes-1.18-release-announcement.md --- ...25-kubernetes-1.18-release-announcement.md | 305 ++++++++++++++++++ 1 file changed, 305 insertions(+) create mode 100644 content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md diff --git a/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md new file mode 100644 index 0000000000..5c0eb0bfbe --- /dev/null +++ b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md @@ -0,0 +1,305 @@ +--- +layout: blog +title: 'Kubernetes 1.18: Fit & Finish' +date: 2020-03-25 +slug: kubernetes-1-18-release-announcement +--- + + +**作者:** [Kubernetes 1.18 发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md) + + +我们很高兴宣布 Kubernetes 1.18 版本的交付，这是我们 2020 年的第一版！ Kubernetes 1.18 包含 38 个增强功能：15 项增强功能已转为稳定版，11 项增强功能处于 beta 阶段，12 项增强功能处于 alpha 阶段。 + + +Kubernetes 1.18 是一个近乎 “完美” 的版本。 为了改善 beta 和稳定的特性，已进行了大量工作，以确保用户获得更好的体验。 我们在增强现有功能的同时也增加了令人兴奋的新特性，这些有望进一步增强用户体验。 + +对 alpha，beta 和稳定版进行几乎同等程度的增强是一项伟大的成就。 它展现了社区在提高 Kubernetes 的可靠性以及继续扩展其现有功能方面所做的巨大努力。 + + + +## 主要内容 + + +### Kubernetes 拓扑管理器（Topology Manager）进入 Beta 阶段 - 对齐！ + + +Kubernetes 在 1.18 版中的 Beta 阶段功能 [拓扑管理器特性](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) 启用 CPU 和设备（例如 SR-IOV VF）的 NUMA 对齐，这将使您的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前，CPU 和设备管理器将做出彼此独立的资源分配决策。 这可能会导致在多处理器系统上非预期的资源分配结果，从而导致对延迟敏感的应用程序的性能下降。 + + +### Serverside Apply 推出Beta 2 + + +Serverside Apply 在1.16 中进入 Beta 阶段，但现在在 1.18 中进入了第二个 Beta 阶段。 这个新版本将跟踪和管理所有新 Kubernetes 对象的字段更改，从而使您知道什么更改了资源以及何时发生了更改。 + + + +### 使用 IngressClass 扩展 Ingress 并用 IngressClass 替换已弃用的注释 + + +在 Kubernetes 1.18 中，Ingress 有两个重要的补充：一个新的 `pathType` 字段和一个新的 `IngressClass` 资源。`pathType` 字段允许指定路径的匹配方式。 除了默认的`ImplementationSpecific`类型外，还有新的 `Exact`和`Prefix` 路径类型。 + + +`IngressClass` 资源用于描述 Kubernetes 集群中 Ingress 的类型。 Ingress 对象可以通过在Ingress 资源类型上使用新的`ingressClassName` 字段来指定与它们关联的类。 这个新的资源和字段替换了不再建议使用的 `kubernetes.io/ingress.class` 注解。 + + +### SIG-CLI 引入了 kubectl alpha debug + + +SIG-CLI 一直在争论着调试工具的必要性。随着 [临时容器](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) 的发展，我们如何使用基于 `kubectl exec` 的工具来支持开发人员的必要性变得越来越明显。 [`kubectl alpha debug` 命令](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 的增加，（由于是 alpha 阶段，非常欢迎您反馈意见），使开发人员可以轻松地在集群中调试 Pod。我们认为这个功能的价值非常高。 此命令允许创建一个临时容器，该容器在要尝试检查的 Pod 旁边运行，并且还附加到控制台以进行交互式故障排除。 + + +### 为 Kubernetes 引入 Windows CSI 支持（Alpha） + + +用于 Windows 的 CSI 代理的 Alpha 版本随 Kubernetes 1.18 一起发布。 CSI 代理通过允许Windows 中的容器执行特权存储操作来启用 Windows 上的 CSI 驱动程序。 + + +## 其它更新 + + +### 毕业转为稳定版 + + +- [基于污点的逐出操作](https://github.com/kubernetes/enhancements/issues/166) +- [`kubectl diff`](https://github.com/kubernetes/enhancements/issues/491) +- [CSI 块存储支持](https://github.com/kubernetes/enhancements/issues/565) +- [API 服务器 dry run](https://github.com/kubernetes/enhancements/issues/576) +- [在 CSI 调用中传递 Pod 信息](https://github.com/kubernetes/enhancements/issues/603) +- [支持树外 vSphere 云驱动](https://github.com/kubernetes/enhancements/issues/670) +- [对 Windows 负载支持 GMSA](https://github.com/kubernetes/enhancements/issues/689) +- [对不可挂载的CSI卷跳过挂载](https://github.com/kubernetes/enhancements/issues/770) +- [PVC 克隆](https://github.com/kubernetes/enhancements/issues/989) +- [移动 kubectl 包代码到 staging](https://github.com/kubernetes/enhancements/issues/1020) +- [Windows 的 RunAsUserName](https://github.com/kubernetes/enhancements/issues/1043) +- [服务和端点的 AppProtocol](https://github.com/kubernetes/enhancements/issues/1507) +- [扩展 Hugepage 特性](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601) +- [Node-local DNS cache](https://github.com/kubernetes/enhancements/issues/1024) + + + +### 主要变化 + + +- [EndpointSlice API](https://github.com/kubernetes/enhancements/issues/752) +- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020) +- [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513) +- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539) +- [client-go 的调用规范重构来标准化选项和管理上下文](https://github.com/kubernetes/enhancements/issues/1601) + + + +### 发布说明 + + +在我们的 [发布文档](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md)中查看 Kubernetes 1.18 发行版的完整详细信息。 + + + +### 下载安装 + + +Kubernetes 1.18 可以在 [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0) 上下载。 要开始使用Kubernetes，请查看这些 [交互教程](https://kubernetes.io/docs/tutorials/) 或通过[kind](https://kind.sigs.k8s.io/) 使用 Docker 容器运行本地 kubernetes 集群。您还可以使用[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/)轻松安装 1.18。 + + +### 发布团队 + + +通过数百位贡献了技术和非技术内容的个人的努力，使本次发行成为可能。 特别感谢由 Searchable AI 的网站可靠性工程师 Jorge Alarcon Ochoa 领导的[发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)。 34 位发布团队成员协调了发布的各个方面，从文档到测试、验证和功能完整性。 + + +随着 Kubernetes 社区的发展壮大，我们的发布过程很好地展示了开源软件开发中的协作。 Kubernetes 继续快速获取新用户。 这种增长创造了一个积极的反馈回路，其中有更多的贡献者提交了代码，从而创建了更加活跃的生态系统。 迄今为止，Kubernetes 已有 [40,000 独立贡献者](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) 和一个超过3000人的活跃社区。 + + +### 发布 logo + + +![Kubernetes 1.18 发布图标](/images/blog/2020-03-25-kubernetes-1.18-release-announcement/release-logo.png) + + +#### 为什么是 LHC + + +LHC 是世界上最大，功能最强大的粒子加速器。，是来自世界各地成千上万科学家合作的结果。所有这些合作都是为了促进科学的发展。以类似的方式，Kubernetes 已经成为一个聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力的项目！ 发布名称“ A Bit Quarky” 的意思是提醒我们，非常规的想法可以带来巨大的变化，对开放性保持开放态度将有助于我们进行创新。 + + + +#### 关于设计者 + + +Maru Lango 是目前居住在墨西哥城的设计师。她的专长是产品设计，她还喜欢使用 CSS + JS 进行品牌、插图和视觉实验，为技术和设计社区的多样性做贡献。您可能会在大多数社交媒体上以 @marulango 的身份找到她，或查看她的网站： https://marulango.com + + +### 高光用户 + + +- 爱立信正在使用 Kubernetes 和其他云原生技术来交付[高标准的 5G 网络](https://www.cncf.io/case-study/ericsson/)，这可以在 CI/CD 上节省多达 90％ 的支出。 +- Zendesk 正在使用 Kubernetes [运行其现有应用程序的约 70％](https://www.cncf.io/case-study/zendesk/)。它还正在使所构建的所有新应用都可以在 Kubernetes 上运行，从而节省时间、提高灵活性并加快其应用程序开发的速度。 +- LifeMiles 因迁移到 Kubernetes 而[降低了 50% 的基础设施开支](https://www.cncf.io/case-study/lifemiles/)。Kubernetes 还使他们可以将其可用资源容量增加一倍。 + + +### 生态系统更新 + + +- CNCF发布了[年度调查](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/) 的结果，表明 Kubernetes 在生产中的使用正在飞速增长。调查发现，有78％的受访者在生产中使用Kubernetes，而去年这一比例为 58％。 +- CNCF 举办的 “Kubernetes入门” 课程有[超过 100,000 人注册](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/)。 + + +### 项目速度 + + +CNCF 继续完善 DevStats。这是一个雄心勃勃的项目，旨在对项目中的无数贡献数据进行可视化展示。[K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) 展示了主要公司贡献者的贡献细目，以及一系列令人印象深刻的预定义的报告，涉及从贡献者个人的各方面到 PR 生命周期的各个方面。 + + +在过去的一个季度中，641 家不同的公司和超过 6,409 个个人为 Kubernetes 作出贡献。 [查看 DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) 以了解有关 Kubernetes 项目和社区发展速度的信息。 + + +### 活动信息 + + +Kubecon + CloudNativeCon EU 2020 已经推迟 - 有关最新信息，请查看[新型肺炎发布页面](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/)。 + + +### 即将到来的发布的线上会议 + + +在 2020 年 4 月 23 日，和 Kubernetes 1.18 版本团队一起了解此版本的主要功能，包括 kubectl debug、拓扑管理器、Ingress 毕业为 V1 版本以及 client-go。 在此处注册：https://www.cncf.io/webinars/kubernetes-1-18/ 。 + + +### 如何参与 + + +参与 Kubernetes 的最简单方法是加入众多与您的兴趣相关的 [特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) 之一。 您有什么想向 Kubernetes 社区发布的内容吗？ 参与我们的每周 [社区会议](https://github.com/kubernetes/community/tree/master/communication)，并通过以下渠道分享您的声音。 感谢您一直以来的反馈和支持。 + + +- 在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio)，了解最新动态 +- 在 [Discuss](https://discuss.kubernetes.io/) 上参与社区讨论 +- 加入 [Slack](http://slack.k8s.io/) 上的社区 +- 在[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)提问（或回答） +- 分享您的 Kubernetes [故事](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) +- 通过 [blog](https://kubernetes.io/blog/)了解更多关于 Kubernetes 的新鲜事 +- 了解更多关于 [Kubernetes 发布团队](https://github.com/kubernetes/sig-release/tree/master/release-team) 的信息 From 67e4e935b71dc4d0cfe89b1a07e06b9ff42b38a2 Mon Sep 17 00:00:00 2001 From: wxsm Date: Thu, 9 Jul 2020 18:46:35 +0800 Subject: [PATCH 47/99] fix: zh doc mislead to en link. --- content/zh/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index bda7bb3dc1..c4da73af47 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -59,7 +59,7 @@ maximum length of a Job name is no more than 63 characters. For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). --> -有关创建和使用 CronJob 的说明及规范文件的示例，请参见[使用 CronJob 运行自动化任务](/docs/tasks/job/automated-tasks-with-cron-jobs)。 +有关创建和使用 CronJob 的说明及规范文件的示例，请参见[使用 CronJob 运行自动化任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)。 From 6ef4cdc96ca7d79cd5af5fc0b637886a4b0e6b41 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 10 Jul 2020 00:25:54 +0900 Subject: [PATCH 48/99] Fix the usage of skew shortcode in the version-skew-policy page. --- content/en/docs/setup/release/version-skew-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index 8a7c332cf2..08abfe7bd5 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -158,4 +158,4 @@ Example: If `kube-proxy` version is **{{< skew latestVersion >}}**: * `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**. -* `kube-apiserver` version must be between **{{ skew oldestMinorVersion }}** and **{{ skew latestVersion }}**, inclusive. +* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive. From 043737c6b657eaebc5aa5a38824c14a7bccdb518 Mon Sep 17 00:00:00 2001 From: Marcos Date: Thu, 9 Jul 2020 14:57:15 -0300 Subject: [PATCH 49/99] Update deployment.md --- content/en/docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6b117cdc44..67582e9041 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -1068,7 +1068,7 @@ allowed, which is the default if not specified. ### Selector -`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/) +`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/) for the Pods targeted by this Deployment. `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API. From 0f8593d1b72c81286a82386352f17a61e6316acd Mon Sep 17 00:00:00 2001 From: jay vyas Date: Thu, 9 Jul 2020 17:47:08 -0400 Subject: [PATCH 50/99] Update statefulset.md --- .../en/docs/concepts/workloads/controllers/statefulset.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4f8429d668..0611f6a9a4 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -141,6 +141,12 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. +Note initial availability of stable DNS name's responsiveness: The initial reachability of a Pod via its DNS +depends on the settings of your DNS provider. It may be 30 seconds before the DNS name for your Pod +is reachable from another Pod in your cluster. For StatefulSets which need to come online via a quorum +in a very short (< 30s) time period, consider tuning your DNS settings +or another mechanism (such as querying the Kubernetes endpoints directly for IP addresses). + As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) responsible for the network identity of the pods. From f604a4b60a4049500c831bdf1f92837379412ca2 Mon Sep 17 00:00:00 2001 From: June Yi Date: Fri, 10 Jul 2020 12:38:02 +0900 Subject: [PATCH 51/99] Seventh Korean l10n work for release 1.18 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Translate reference/command-line-tools-reference/feature-gates.md int… (#22240) - Fix issue of broken links to translated docs (#22105) - Fix issue of document link in some ko documents (#22379) - Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776) - Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362) - Fix issue of broken links to translated docs #2 (#22270) - Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261) - Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263) - Fix incorrect notation of 'directory' into Korean (#22155) - Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232) - Update outdated files in dev-1.18-ko.7 (#22128) - Modify spacing term ReplicaSet in Korean (#22148) - Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849) - Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730) Co-authored-by: Jerry Park Co-authored-by: woopyoung Co-authored-by: coolguyhong Co-authored-by: PyungHo Yoon Co-authored-by: Seokho Son Co-authored-by: jmyung Co-authored-by: Ian Y. Choi --- content/ko/docs/concepts/_index.md | 7 +- .../ko/docs/concepts/architecture/nodes.md | 68 +-- .../concepts/cluster-administration/addons.md | 4 +- .../cluster-administration/cloud-providers.md | 2 +- .../cluster-administration-overview.md | 10 +- .../docs/concepts/configuration/configmap.md | 9 +- .../manage-resources-containers.md | 2 +- .../organize-cluster-access-kubeconfig.md | 4 +- .../docs/concepts/configuration/overview.md | 20 +- .../concepts/configuration/pod-overhead.md | 2 +- .../configuration/resource-bin-packing.md | 20 +- content/ko/docs/concepts/containers/images.md | 263 ++++----- .../docs/concepts/containers/runtime-class.md | 12 +- .../api-extension/custom-resources.md | 5 +- .../compute-storage-net/device-plugins.md | 6 +- .../extend-kubernetes/extend-cluster.md | 18 +- .../ko/docs/concepts/overview/components.md | 10 +- .../docs/concepts/overview/kubernetes-api.md | 3 + .../concepts/overview/what-is-kubernetes.md | 3 +- .../overview/working-with-objects/_index.md | 3 + .../working-with-objects/annotations.md | 4 +- .../working-with-objects/field-selectors.md | 2 +- .../overview/working-with-objects/labels.md | 2 +- .../working-with-objects/namespaces.md | 12 +- .../working-with-objects/object-management.md | 36 +- .../ko/docs/concepts/policy/limit-range.md | 10 +- .../concepts/policy/pod-security-policy.md | 5 +- .../docs/concepts/policy/resource-quotas.md | 7 +- .../scheduling-eviction/kube-scheduler.md | 2 +- .../taint-and-toleration.md | 2 +- content/ko/docs/concepts/security/overview.md | 149 +++-- ...ries-to-pod-etc-hosts-with-host-aliases.md | 56 +- .../connect-applications-service.md | 6 +- .../services-networking/endpoint-slices.md | 3 +- .../concepts/services-networking/ingress.md | 7 +- .../concepts/services-networking/service.md | 16 +- .../concepts/storage/persistent-volumes.md | 4 +- .../docs/concepts/storage/storage-classes.md | 21 +- .../storage/volume-snapshot-classes.md | 35 +- .../docs/concepts/storage/volume-snapshots.md | 10 +- content/ko/docs/concepts/storage/volumes.md | 4 +- .../workloads/controllers/daemonset.md | 4 +- .../workloads/controllers/deployment.md | 22 +- .../controllers/garbage-collection.md | 10 +- .../{jobs-run-to-completion.md => job.md} | 0 .../workloads/controllers/replicaset.md | 12 +- .../controllers/replicationcontroller.md | 6 +- .../workloads/controllers/statefulset.md | 2 +- .../workloads/controllers/ttlafterfinished.md | 6 +- .../workloads/pods/init-containers.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 3 +- .../pods/pod-topology-spread-constraints.md | 2 +- .../ko/docs/concepts/workloads/pods/pod.md | 4 +- content/ko/docs/contribute/_index.md | 12 +- content/ko/docs/contribute/advanced.md | 1 + .../docs/contribute/new-content/open-a-pr.md | 24 +- content/ko/docs/contribute/participating.md | 8 +- .../docs/contribute/review/reviewing-prs.md | 6 +- .../docs/contribute/style/write-new-topic.md | 35 +- content/ko/docs/home/_index.md | 2 + .../command-line-tools-reference/_index.md | 5 + .../feature-gates.md | 518 ++++++++++++++++++ content/ko/docs/reference/glossary/cni.md | 12 +- content/ko/docs/reference/glossary/cronjob.md | 4 +- .../docs/reference/glossary/device-plugin.md | 2 +- content/ko/docs/reference/glossary/docker.md | 2 +- content/ko/docs/reference/glossary/job.md | 2 +- .../ko/docs/reference/glossary/minikube.md | 3 +- content/ko/docs/reference/glossary/volume.md | 4 +- .../ko/docs/reference/kubectl/cheatsheet.md | 11 +- content/ko/docs/reference/kubectl/overview.md | 65 ++- content/ko/docs/reference/tools.md | 5 +- .../docs/reference/using-api/api-overview.md | 7 +- .../reference/using-api/client-libraries.md | 2 +- content/ko/docs/setup/_index.md | 4 +- .../docs/setup/best-practices/certificates.md | 2 +- .../setup/best-practices/cluster-large.md | 5 +- .../setup/best-practices/multiple-zones.md | 6 +- .../setup/best-practices/node-conformance.md | 1 - .../setup/learning-environment/minikube.md | 8 +- .../container-runtimes.md | 22 +- .../production-environment/tools/kops.md | 20 +- content/ko/docs/tasks/_index.md | 73 +-- .../access-application-cluster/_index.md | 1 + .../access-cluster.md | 2 +- ...icate-containers-same-pod-shared-volume.md | 7 +- .../configure-access-multiple-clusters.md | 34 +- .../web-ui-dashboard.md | 12 +- .../docs/tasks/administer-cluster/_index.md | 1 + .../administer-cluster/access-cluster-api.md | 451 +++++++++++++++ .../access-cluster-services.md | 134 +++++ .../change-default-storage-class.md | 24 +- .../administer-cluster/cluster-management.md | 68 ++- .../extended-resource-node.md | 206 +++++++ .../kubeadm/adding-windows-nodes.md | 32 +- .../kubeadm/kubeadm-upgrade.md | 2 +- .../kubeadm/upgrading-windows-nodes.md | 12 +- .../cpu-constraint-namespace.md | 5 +- .../manage-resources/cpu-default-namespace.md | 4 +- .../memory-constraint-namespace.md | 4 +- .../memory-default-namespace.md | 6 +- .../quota-memory-cpu-namespace.md | 4 +- .../manage-resources/quota-pod-namespace.md | 9 +- .../cilium-network-policy.md | 2 +- .../romana-network-policy.md | 4 - .../tasks/configure-pod-container/_index.md | 1 + .../assign-memory-resource.md | 29 +- .../assign-pods-nodes-using-node-affinity.md | 3 +- .../configure-pod-initialization.md | 4 - .../configure-pod-container/static-pod.md | 50 +- .../tasks/debug-application-cluster/_index.md | 1 + .../determine-reason-pod-failure.md | 50 +- .../resource-metrics-pipeline.md | 26 +- .../tasks/extend-kubectl/kubectl-plugins.md | 2 +- .../tasks/inject-data-application/_index.md | 4 +- .../define-command-argument-container.md | 24 +- content/ko/docs/tasks/manage-daemon/_index.md | 1 + .../manage-daemon/rollback-daemon-set.md | 66 +-- .../docs/tasks/manage-gpus/scheduling-gpus.md | 5 +- .../manage-hugepages/scheduling-hugepages.md | 16 +- .../tasks/manage-kubernetes-objects/_index.md | 1 + .../declarative-config.md | 4 +- .../imperative-command.md | 4 +- .../imperative-config.md | 4 +- .../kustomization.md | 54 +- content/ko/docs/tasks/network/_index.md | 3 +- .../docs/tasks/network/validate-dual-stack.md | 4 +- .../ko/docs/tasks/run-application/_index.md | 1 + .../run-application/delete-stateful-set.md | 6 +- .../horizontal-pod-autoscale-walkthrough.md | 2 +- .../horizontal-pod-autoscale.md | 12 +- content/ko/docs/tasks/tls/_index.md | 1 + content/ko/docs/tasks/tools/_index.md | 1 + .../ko/docs/tasks/tools/install-kubectl.md | 238 ++++---- .../ko/docs/tasks/tools/install-minikube.md | 14 +- content/ko/docs/tutorials/_index.md | 2 +- .../configure-redis-using-configmap.md | 4 +- content/ko/docs/tutorials/hello-minikube.md | 2 +- .../expose/expose-intro.html | 4 +- .../kubernetes-basics/scale/scale-intro.html | 2 +- .../ko/docs/tutorials/services/source-ip.md | 2 +- .../basic-stateful-set.md | 294 +++++++--- .../mysql-wordpress-persistent-volume.md | 6 +- .../stateful-application/zookeeper.md | 26 +- .../expose-external-ip-address.md | 13 +- .../guestbook-logs-metrics-with-elk.md | 2 +- .../stateless-application/guestbook.md | 11 +- content/ko/partners/_index.html | 123 +++-- 148 files changed, 2604 insertions(+), 1350 deletions(-) rename content/ko/docs/concepts/workloads/controllers/{jobs-run-to-completion.md => job.md} (100%) create mode 100644 content/ko/docs/reference/command-line-tools-reference/_index.md create mode 100644 content/ko/docs/reference/command-line-tools-reference/feature-gates.md create mode 100644 content/ko/docs/tasks/administer-cluster/access-cluster-api.md create mode 100644 content/ko/docs/tasks/administer-cluster/access-cluster-services.md create mode 100644 content/ko/docs/tasks/administer-cluster/extended-resource-node.md diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 34bc413e74..89b8e7910c 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -41,7 +41,7 @@ weight: 40 * [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) * [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/) * [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) ## 쿠버네티스 컨트롤 플레인 @@ -66,6 +66,5 @@ weight: 40 개념 페이지를 작성하기를 원하면, -개념 페이지 유형에 대한 정보가 있는 -[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다. - +개념 페이지 타입에 대한 정보가 있는 +[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index e4f5c9564e..54782a20e3 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -63,11 +63,11 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 {{< /note >}} 노드 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ### 노드에 대한 자체-등록 -kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 +kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다. 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다. @@ -75,7 +75,7 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법. - `--register-node` - 자동으로 API 서버에 등록. - - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `=:`)를 가진 노드 등록. + - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `=:`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안 함. - `--node-ip` - 노드의 IP 주소. @@ -180,7 +180,7 @@ kubectl describe node ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 -강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 +강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. @@ -188,7 +188,7 @@ ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text=" apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 -[테인트(taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. +[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. @@ -197,7 +197,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 ### 용량과 할당가능 {#capacity} -노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 +노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다. 용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다. @@ -221,18 +221,18 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다. -두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 -사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 -동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 -해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, +두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 +사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 +동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 +해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. -세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 -노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 +세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 +노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) -NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, -노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. -(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, +NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, +노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. +(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. @@ -260,30 +260,30 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 #### 안정성 - 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 -축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 + 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 +축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다. 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 -경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 -체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). -상태가 불량한 노드의 일부가 최소 +경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 +체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). +상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 -되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 -`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, -그렇지 않으면 축출 비율은 초당 -`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. -이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 -하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. -만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, +되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 +`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, +그렇지 않으면 축출 비율은 초당 +`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. +이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 +하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. +만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다. -노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 -장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. -그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 -`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 -완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. -이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 +노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 +장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. +그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 +`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 +완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. +이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다. 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 @@ -323,7 +323,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} -`TopologyManager` +`TopologyManager` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. 자세한 내용은 diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 9e6f5ab7ec..1838688d38 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -33,7 +33,7 @@ content_type: concept * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. -* [Romana](http://romana.io)는 [네트워크폴리시 API](/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. +* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. ## 서비스 검색 @@ -54,5 +54,3 @@ content_type: concept 더 이상 사용되지 않는 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 디렉터리에 다른 여러 애드온이 문서화되어 있다. 잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다! - - diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 91e1a4e7ac..3d5ba7e9d0 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -99,7 +99,7 @@ _어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다. diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md index d454b85ca0..2efa8436fb 100644 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -19,12 +19,12 @@ weight: 10 - 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자. - [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**? - 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다. - - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다. + - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다. - 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지? - **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면, 적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만, 매우 다양한 선택권을 제공한다. - - 스스로 클러스터 구동에 필요한 [구성요소](/docs/admin/cluster-components/)에 익숙해지자. + - 스스로 클러스터 구동에 필요한 [구성요소](/ko/docs/concepts/overview/components/)에 익숙해지자. 참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자. @@ -38,7 +38,7 @@ weight: 10 ## 클러스터 보안 -* [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. +* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. @@ -63,6 +63,4 @@ weight: 10 * [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다. -* [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. - - +* [클러스터 활동 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index f61add3919..542fef1bcc 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -60,7 +60,7 @@ metadata: name: game-demo data: # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨 - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # 파일과 비슷한 키 @@ -85,9 +85,9 @@ data: 방식에 따라 다르게 쓰인다. 처음 세 가지 방법의 경우, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 파드의 컨테이너를 시작할 때 -시크릿의 데이터를 사용한다. +컨피그맵의 데이터를 사용한다. -네 번째 방법은 시크릿과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. +네 번째 방법은 컨피그맵과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. 그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은 컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가 있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이 @@ -168,7 +168,7 @@ spec: 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. 1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다. -1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다. +1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다. 1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. 1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다. @@ -250,4 +250,3 @@ immutable: true * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다. * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. - diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 90991bc49e..1e20865133 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -227,7 +227,7 @@ kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을 파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다. kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에 -[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) +[`emptyDir`](/ko/docs/concepts/storage/volumes/#emptydir) {{< glossary_tooltip term_id="volume" text="볼륨" >}}을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다. kubelet은 이러한 종류의 스토리지를 사용하여 diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 483e664e24..a002414b67 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -58,8 +58,8 @@ kubectl config use-context ## KUBECONFIG 환경 변수 `KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다. -Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. -Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. +리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. +윈도우는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. `KUBECONFIG` 환경 변수가 없으면, `kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index db45ca2d2c..387a794a6b 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -28,16 +28,16 @@ weight: 10 - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다. -## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs} +## "단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job) {#naked-pods-vs-replicasets-deployments-and-jobs} -- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. +- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. - 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. + 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다. ## 서비스 -- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. ```shell FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> @@ -46,7 +46,7 @@ weight: 10 *이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다. -- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. +- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다. - 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다. @@ -61,13 +61,13 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 ## 레이블 사용하기 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. -- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. +- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. ## 컨테이너 이미지 @@ -99,8 +99,6 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. -- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. - -- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. - +- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다. +- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index 3dd850067c..6b7aa489b1 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -83,7 +83,7 @@ spec: memory: 100Mi ``` -어드미션 수행 시에, [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)는 +어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는 런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, 파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 `overhead` 를 포함하도록 변경한다. diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 4a8a6b7f2f..998456ca49 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -128,23 +128,23 @@ CPU: 1 Node Score: intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) - = 7 + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 # requested + used = 75% * available + = rawScoringFunction(75) + = 7 # floor(75/10) Memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) - = 50 + = 50 # requested + used = 50% * available = rawScoringFunction(50) - = 5 + = 5 # floor(50/10) CPU = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) - = 37.5 + = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) - = 3 + = 3 # floor(37.5/10) NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 @@ -189,5 +189,3 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - - diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index f03847c38c..0f7bb0cb13 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -6,18 +6,51 @@ weight: 10 -사용자 Docker 이미지를 생성하고 레지스트리에 푸시(push)하여 쿠버네티스 파드에서 참조되기 이전에 대비한다. +컨테이너 이미지는 애플리케이션과 모든 소프트웨어 의존성을 캡슐화하는 바이너리 데이터를 +나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해 +잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다. -컨테이너의 `image` 속성은 `docker` 커맨드에서 지원하는 문법과 같은 문법을 지원한다. 이는 프라이빗 레지스트리와 태그를 포함한다. +일반적으로 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 +참조하기 전에 애플리케이션의 컨테이너 이미지를 +생성해서 레지스트리로 푸시한다. + +이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. +## 이미지 이름 + +컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다. +이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename` +과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다. + +레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다. + +이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 와 `podman` +등의 명령과 함께 사용). +태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다. + +이미지 태그는 소문자와 대문자, 숫자, 밑줄(`_`), +마침표(`.`) 및 대시(`-`)로 구성된다. +이미지 태그 안에서 구분 문자(`_`, `-` 그리고 `.`)를 +배치할 수 있는 위치에 대한 추가 규칙이 있다. +태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다. + +{{< caution >}} +프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다. +실행 중인 이미지 버전을 추적하기가 어렵고 +이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다. + +대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다. +{{< /caution >}} + ## 이미지 업데이트 -기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 Kubelet이 이미 +기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. @@ -26,46 +59,18 @@ weight: 10 - `imagePullPolicy`와 사용할 이미지의 태그를 생략. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. -`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다. +`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. -## 매니페스트로 멀티-아키텍처 이미지 빌드 +## 매니페스트가 있는 다중 아키텍처 이미지 -Docker CLI는 현재 `docker manifest` 커맨드와 `create`, `annotate`, `push`와 같은 서브 커맨드를 함께 지원한다. 이 커맨드는 매니페스트를 빌드하고 푸시하는데 사용할 수 있다. 매니페스트를 보기 위해서는 `docker manifest inspect`를 사용하면 된다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. -다음에서 docker 문서를 확인하기 바란다. -https://docs.docker.com/edge/engine/reference/commandline/manifest/ - -이것을 사용하는 방법에 대한 예제는 빌드 하니스(harness)에서 참조한다. -https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos= - -이 커맨드는 Docker CLI에 의존하며 그에 전적으로 구현된다. `$HOME/.docker/config.json` 편집 및 `experimental` 키를 `enabled`로 설정하거나, CLI 커맨드 호출 시 간단히 `DOCKER_CLI_EXPERIMENTAL` 환경 변수를 `enabled`로만 설정해도 된다. - -{{< note >}} -Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전은 버그가 있거나 실험적인 명령줄 옵션을 지원하지 않는다. 예를 들어 https://github.com/docker/cli/issues/1135 는 containerd에서 문제를 일으킨다. -{{< /note >}} - -오래된 매니페스트 업로드를 실행하는 데 어려움을 겪는다면, `$HOME/.docker/manifests`에서 오래된 매니페스트를 정리하여 새롭게 시작하면 된다. - -쿠버네티스의 경우, 일반적으로 접미사 `-$(ARCH)`가 있는 이미지를 사용해 왔다. 하위 호환성을 위해, 접미사가 있는 구형 이미지를 생성하길 바란다. 접미사에 대한 아이디어는 모든 아키텍처를 위한 매니페스트를 가졌다는 의미가 내포된 `pause` 이미지를 생성하고, 접미사가 붙은 이미지가 하드 코드되어 있을 오래된 구성 또는 YAML 파일에 대해 하위 호환된다는 의미가 내포되어 있는 `pause-amd64`를 생성하기 위한 것이다. +쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. ## 프라이빗 레지스트리 사용 프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다. 자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다. - - - Google 컨테이너 레지스트리 사용 - - 각 클러스터에 대하여 - - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨 - - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음 - - AWS Elastic Container Registry(ECR) 사용 - - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - - ECR 로그인 자격 증명은 자동으로 갱신됨 - - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 - - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - - Azure 컨테이너 레지스트리(ACR) 사용 - - IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함 - - IBM 클라우드 컨테이너 레지스트리 사용 - - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 @@ -74,139 +79,57 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 파드에 ImagePullSecrets을 명시 - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능 + - 공급 업체별 또는 로컬 확장 + - 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드 + 제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을 + 구현할 수 있다. -각 옵션은 아래에서 더 자세히 설명한다. +이들 옵션은 아래에서 더 자세히 설명한다. +### 프라이빗 레지스트리에 인증하도록 노드 구성 -### Google 컨테이너 레지스트리 사용 +노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록 +도커 컨테이너 런타임을 구성할 수 있다. -쿠버네티스는 Google 컴퓨트 엔진(GCE)에서 동작할 때, [Google 컨테이너 -레지스트리(GCR)](https://cloud.google.com/tools/container-registry/)를 자연스럽게 -지원한다. 사용자의 클러스터가 GCE 또는 Google 쿠버네티스 엔진에서 동작 중이라면, 간단히 -이미지의 전체 이름(예: gcr.io/my_project/image:tag)을 사용하면 된다. - -클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다. - -Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 -GCR을 인증할 것이다. 인스턴스의 서비스 계정은 -`https://www.googleapis.com/auth/devstorage.read_only`라서, -프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. - -### Amazon Elastic Container Registry 사용 - -쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. - -간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 -파드 정의에 사용하면 된다. - -파드를 생성할 수 있는 클러스터의 모든 사용자는 ECR 레지스트리에 있는 어떠한 -이미지든지 파드를 실행하는데 사용할 수 있다. - -kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다. 이것을 위해서는 다음에 대한 권한이 필요하다. - -- `ecr:GetAuthorizationToken` -- `ecr:BatchCheckLayerAvailability` -- `ecr:GetDownloadUrlForLayer` -- `ecr:GetRepositoryPolicy` -- `ecr:DescribeRepositories` -- `ecr:ListImages` -- `ecr:BatchGetImage` - -요구 사항: - -- Kubelet 버전 `v1.2.0` 이상을 사용해야 한다. (예: `/usr/bin/kubelet --version=true`를 실행). -- 노드가 지역 A에 있고 레지스트리가 다른 지역 B에 있다면, 버전 `v1.3.0` 이상이 필요하다. -- 사용자의 지역에서 ECR이 지원되어야 한다. - -문제 해결: - -- 위의 모든 요구 사항을 확인한다. -- 워크스테이션에서 $REGION (예: `us-west-2`)의 자격 증명을 얻는다. 그 자격 증명을 사용하여 해당 호스트로 SSH를 하고 Docker를 수동으로 실행한다. 작동하는가? -- kubelet이 `--cloud-provider=aws`로 실행 중인지 확인한다. -- kubelet 로그 수준을 최소 3 이상으로 늘리고 kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다. - - `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` - -### Azure 컨테이너 레지스트리(ACR) 사용 -쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때 -[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를 -기본적으로 지원한다. - -AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한 -지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다. - -ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다. -어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 -[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다. - -우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 -[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. - -컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다. - - * `DOCKER_USER` : 서비스 주체 또는 관리자 역할의 사용자명 - * `DOCKER_PASSWORD`: 서비스 주체 패스워드 또는 관리자 역할의 사용자 패스워드 - * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` - * `DOCKER_EMAIL`: `${some-email-address}` - -해당 변수에 대한 값을 채우고 나면 -[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다. - -### IBM 클라우드 컨테이너 레지스트리 사용 -IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다. - -IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)를 참고한다. - -다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다. - -### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 +이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다. {{< note >}} -Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - -{{< note >}} -AWS EC2에서 동작 중이고 EC2 컨테이너 레지스트리(ECR)을 사용 중이라면, 각 노드의 kubelet은 -ECR 로그인 자격 증명을 관리하고 업데이트할 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - -{{< note >}} -이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. -{{< /note >}} - -{{< note >}} -현재 쿠버네티스는 docker 설정의 `auths`와 `HttpHeaders` 섹션만 지원한다. 이는 자격증명 도우미(`credHelpers` 또는 `credStore`)가 지원되지 않는다는 뜻이다. +쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다. +도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다. {{< /note >}} -Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 +도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다. -* `{--root-dir:-/var/lib/kubelet}/config.json` -* `{cwd of kubelet}/config.json` -* `${HOME}/.docker/config.json` -* `/.docker/config.json` -* `{--root-dir:-/var/lib/kubelet}/.dockercfg` -* `{cwd of kubelet}/.dockercfg` -* `${HOME}/.dockercfg` -* `/.dockercfg` +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` {{< note >}} -아마도 kubelet을 위한 사용자의 환경 파일에 `HOME=/root`을 명시적으로 설정해야 할 것이다. +kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설정해야 할 수 있다. {{< /note >}} 프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다. - 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 `$HOME/.docker/config.json`를 업데이트한다. + 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다. 1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다. 1. 노드의 리스트를 구한다. 예를 들면 다음과 같다. - - 이름을 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - - IP를 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + - 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다. - - 예: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` + - 이를 테스트하기 위한 예: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록 +구성 관리 도구를 사용한다. +{{< /note >}} 프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다. @@ -263,11 +186,11 @@ Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Go {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. +클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로 +작동하지 않을 것이다. {{< /note >}} -기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 할 것이다. +기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다. 그러나, 컨테이너의 `imagePullPolicy` 속성이 `IfNotPresent` 또는 `Never`으로 설정되어 있다면, 로컬 이미지가 사용된다(우선적으로 또는 배타적으로). @@ -281,13 +204,13 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 ### 파드에 ImagePullSecrets 명시 {{< note >}} -이 방법은 현재 Google 쿠버네티스 엔진, GCE 및 노드 생성이 자동화된 모든 클라우드 제공자에게 +이 방법은 프라이빗 레지스트리의 이미지를 기반으로 컨테이너를 실행하는 데 권장된다. {{< /note >}} -쿠버네티스는 파드에 레지스트리 키를 명시하는 것을 지원한다. +쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다. -#### Docker 구성으로 시크릿 생성 +#### 도커 구성으로 시크릿 생성 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다. @@ -295,12 +218,14 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL ``` -만약 Docker 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, -자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다. -[기존 Docker 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. +만약 도커 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, +자격 증명 파일을 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}으로 +가져올 수 있다. +[기존 도커 자격 증명으로 시크릿 생성](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. + `kubectl create secret docker-registry`는 -하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, -여러 개인 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. +하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, +여러 프라이빗 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. {{< note >}} 파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다. @@ -312,6 +237,8 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER 이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을 참조하는 파드를 생성할 수 있다. +예를 들면 다음과 같다. + ```shell cat < pod.yaml apiVersion: v1 @@ -337,28 +264,29 @@ EOF 그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다. + 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다. 이것은 노드 당 `.docker/config.json`와 함께 사용할 수 있다. 자격 증명은 -병합될 것이다. 이 방법은 Google 쿠버네티스 엔진에서 작동될 것이다. +병합될 것이다. -### 유스케이스 +## 유스케이스 프라이빗 레지스트리를 구성하기 위한 많은 솔루션이 있다. 다음은 여러 가지 일반적인 유스케이스와 제안된 솔루션이다. 1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다. - - Docker hub의 퍼블릭 이미지를 사용한다. + - 도커 허브의 퍼블릭 이미지를 사용한다. - 설정이 필요 없다. - - GCE 및 Google 쿠버네티스 엔진에서는, 속도와 가용성 향상을 위해서 로컬 미러가 자동적으로 사용된다. + - 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다. 1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를 실행하는 클러스터의 경우. - - 호스트 된 프라이빗 [Docker 레지스트리](https://docs.docker.com/registry/)를 사용한다. - - 그것은 [Docker Hub](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. + - 호스트 된 프라이빗 [도커 레지스트리](https://docs.docker.com/registry/)를 사용한다. + - 그것은 [도커 허브](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. - 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다. - 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다. - 쿠버네티스 구성은 필요 없다. - - 또는, GCE 및 Google 쿠버네티스 엔진에서는, 프로젝트의 Google 컨테이너 레지스트리를 사용한다. + - 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다. - 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다. - 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다. 1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우. @@ -372,5 +300,8 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. -Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. +Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다. +## {{% heading "whatsnext" %}} + +* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기 diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 54500e7ad8..ea661af0c6 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -72,7 +72,7 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` 런타임클래스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)어이야 한다. {{< note >}} 런타임클래스 쓰기 작업(create/update/patch/delete)은 @@ -97,7 +97,7 @@ spec: 이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 -`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다. +`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 확인한다. @@ -106,7 +106,7 @@ spec: ### CRI 구성 {#cri-configuration} -CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다. +CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/production-environment/container-runtimes/)를 확인한다. #### dockershim @@ -155,7 +155,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md 파드는 거부된다. 지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, -`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 +`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다. @@ -183,7 +183,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c - [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) -- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 +- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 0d7c08a9a4..159c0fc846 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -25,7 +25,7 @@ weight: 10 동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며 클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다. 커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로 -[kubectl](/docs/user-guide/kubectl-overview/)을 사용하여 해당 오브젝트를 생성하고 +[kubectl](/ko/docs/reference/kubectl/overview/)을 사용하여 해당 오브젝트를 생성하고 접근할 수 있다. ## 커스텀 컨트롤러 @@ -234,7 +234,7 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 ## 커스텀 리소스에 접근 -쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. +쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. @@ -251,4 +251,3 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. * [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. - diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 553ab99cf0..bf4eb55898 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -38,7 +38,7 @@ service Registration { * 유닉스 소켓의 이름. * 빌드된 장치 플러그인 API 버전. * 알리려는 `ResourceName`. 여기서 `ResourceName` 은 - [확장된 리소스 네이밍 체계](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)를 + [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 `vendor-domain/resourcetype` 의 형식으로 따라야 한다. (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) @@ -228,9 +228,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. ## {{% heading "whatsnext" %}} -* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 +* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 * 노드에서의 [확장 리소스 알리기](/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index ecf57f49fc..543b5cfa48 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -45,7 +45,7 @@ weight: 10 이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. 대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. -결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 있고 +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. ## 익스텐션 패턴 @@ -70,7 +70,7 @@ weight: 10 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: [Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 -[네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/))과 +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -90,7 +90,7 @@ kubectl에서 -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. 2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. 3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. 4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. @@ -164,7 +164,7 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 ### 장치 플러그인 -장치 플러그인은 노드가 [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/)을 +장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 발견할 수 있게 해준다. @@ -198,9 +198,7 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 * [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 * 인프라스트럭처 익스텐션에 대해 더 알아보기 - * [네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/) - * [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/) -* [kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 -* [오퍼레이터 패턴](/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 - - + * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 8d0efc2212..ace13900c6 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -1,8 +1,11 @@ --- title: 쿠버네티스 컴포넌트 content_type: concept +description: > + 쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 + 컴포넌트로 구성된다. weight: 20 -card: +card: name: concepts weight: 20 --- @@ -96,7 +99,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다. 선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 -[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. +[애드온](/ko/docs/concepts/cluster-administration/addons/)을 참조한다. ### DNS @@ -117,7 +120,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 ### 클러스터-레벨 로깅 -[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 +[클러스터-레벨 로깅](/ko/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다. @@ -127,4 +130,3 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 * [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 - diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index d1d1e3d499..26047a8814 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -2,6 +2,9 @@ title: 쿠버네티스 API content_type: concept weight: 30 +description: > + 쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. + 쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다. card: name: concepts weight: 30 diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index f94ab988a3..ad083dd49d 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -71,7 +71,7 @@ card: ## 쿠버네티스가 아닌 것 -쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는: @@ -89,4 +89,3 @@ card: * [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 * [시작하기](/ko/docs/setup/) 준비가 되었는가? - diff --git a/content/ko/docs/concepts/overview/working-with-objects/_index.md b/content/ko/docs/concepts/overview/working-with-objects/_index.md index a27acb856c..84ea350c8f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/_index.md +++ b/content/ko/docs/concepts/overview/working-with-objects/_index.md @@ -1,4 +1,7 @@ --- title: "쿠버네티스 오브젝트로 작업하기" weight: 40 +description: > + 쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. + 쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다. --- diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index aa9c29cb64..96db884a4f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -51,13 +51,13 @@ weight: 50 * 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트 * 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은 - 해당 정보를 찾을 수 있는 디렉토리 진입점. + 해당 정보를 찾을 수 있는 디렉터리 진입점. * 행동을 수정하거나 비표준 기능을 수행하기 위한 최종 사용자의 지시 사항. 어노테이션을 사용하는 대신, 이 유형의 정보를 -외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 +외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 공유 클라이언트 라이브러리와 도구 생성을 훨씬 더 어렵게 만들 수 있다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md index 9a343ca5c5..cb16ce9d58 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md @@ -9,7 +9,7 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버 * `metadata.namespace!=default` * `status.phase=Pending` -다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다. +다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다. ```shell kubectl get pods --field-selector status.phase=Running diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index e06daff929..ed896ce005 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -87,7 +87,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 문서화해야 한다. {{< note >}} -레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. +레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. {{< /note >}} {{< caution >}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index d5eb45f21c..ec4df0668d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -27,7 +27,7 @@ weight: 30 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다. -이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 +이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다. 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 @@ -39,6 +39,10 @@ weight: 30 네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. +{{< note >}} + 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. +{{< /note >}} + ### 네임스페이스 조회 사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다. @@ -54,11 +58,12 @@ kube-public Active 1d kube-system Active 1d ``` -쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다. +쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다. * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. + * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 ### 요청에 네임스페이스 설정하기 @@ -114,6 +119,3 @@ kubectl api-resources --namespaced=false * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기. - - - diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 9b59aae529..590116af6f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -7,7 +7,7 @@ weight: 15 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을 -제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 +제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다. @@ -40,12 +40,6 @@ weight: 15 디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다. -```sh -kubectl run nginx --image nginx -``` - -다른 문법을 이용하여 동일한 작업을 수행한다. - ```sh kubectl create deployment nginx --image nginx ``` @@ -75,11 +69,11 @@ kubectl create deployment nginx --image nginx 참고한다. {{< warning >}} -명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 -구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. -이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 -사용하지 말아야한다. -예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 +명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 +구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. +이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 +사용하지 말아야한다. +예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 `externalIPs` 필드가 업데이트된다. {{< /warning >}} @@ -124,7 +118,7 @@ kubectl replace -f nginx.yaml 선언형 오브젝트 구성에 비해 단점은 다음과 같다. -- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다. +- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다. - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다. ## 선언형 오브젝트 구성 @@ -133,19 +127,19 @@ kubectl replace -f nginx.yaml 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 `kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 -다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다. +다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다. {{< note >}} -선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 -다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. +선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 +다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 이것은 전체 오브젝트 구성 변경을 위한 `replace` API를 -사용하는 대신, `patch` API를 사용하여 인지되는 차이만 +사용하는 대신, `patch` API를 사용하여 인지되는 차이만 작성하기 때문에 가능하다. {{< /note >}} ### 예시 -`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 +`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff` 하고 나서 적용할 수 있다. @@ -154,7 +148,7 @@ kubectl diff -f configs/ kubectl apply -f configs/ ``` -재귀적으로 디렉토리를 처리한다. +재귀적으로 디렉터리를 처리한다. ```sh kubectl diff -R -f configs/ @@ -166,7 +160,7 @@ kubectl apply -R -f configs/ 명령형 오브젝트 구성에 비해 장점은 다음과 같다. - 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다. -- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다. +- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다. 명령형 오브젝트 구성에 비해 단점은 다음과 같다. @@ -185,5 +179,3 @@ kubectl apply -R -f configs/ - [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl 서적](https://kubectl.docs.kubernetes.io) - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index ee30ec6437..84656375c0 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -61,11 +61,11 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 제한의 사용에 대한 예시는 다음을 참조한다. -- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). -- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). -- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). -- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). +- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). +- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). +- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). - [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). -- [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). +- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index de6ab7a25d..aa3e786af7 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -455,7 +455,7 @@ allowedHostPaths: (다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할 수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다. -쓰기 가능한 hostPath 디렉토리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 +쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다. 쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한 접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다. @@ -592,7 +592,7 @@ spec: ### AppArmor 파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor -문서](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. +문서](/ko/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. ### Seccomp @@ -636,4 +636,3 @@ spec: 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. - diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 7c7a6f64a8..ca1af3adc2 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -33,7 +33,7 @@ weight: 10 - `cpu`, `memory`와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우 사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이 파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 `LimitRanger` 어드미션 컨트롤러를 사용하자. - 이 문제를 회피하는 방법에 대한 예제는 [연습](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)을 참고하길 바란다. + 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. `ResourceQuota` 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. @@ -75,7 +75,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 ### 확장된 리소스에 대한 리소스 쿼터 위에서 언급한 리소스 외에도 릴리스 1.10에서는 -[확장된 리소스](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)에 대한 쿼터 지원이 추가되었다. +[확장된 리소스](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)에 대한 쿼터 지원이 추가되었다. 확장된 리소스에는 오버커밋(overcommit)이 허용되지 않으므로 하나의 쿼터에서 동일한 확장된 리소스에 대한 `requests`와 `limits`을 모두 지정하는 것은 의미가 없다. 따라서 확장된 @@ -197,7 +197,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. {{< feature-state for_k8s_version="v1.12" state="beta" >}} -특정 [우선 순위](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)로 파드를 생성할 수 있다. +특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 제어할 수 있다. @@ -600,4 +600,3 @@ plugins: 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. - diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 576d966a9b..1db0e6a09b 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -28,7 +28,7 @@ weight: 10 ## kube-scheduler -[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)는 +[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)는 쿠버네티스의 기본 스케줄러이며 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부로 실행된다. kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index 2100a6de10..a72b857d07 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -171,7 +171,7 @@ tolerations: 사용자 정의 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 사용하여 톨러레이션를 적용하는 것이 가장 쉬운 방법이다. 예를 들어, [확장된 -리소스](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)를 +리소스](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 사용하여 특별한 하드웨어를 나타내고, 확장된 리소스 이름으로 특별한 하드웨어 노드를 테인트시키고 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index b64f946acc..bcbc22d915 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -1,59 +1,53 @@ --- title: 클라우드 네이티브 보안 개요 content_type: concept -weight: 1 +weight: 10 --- -{{< toc >}} - -쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 -방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 -수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, -전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 -몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 -몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 -소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 -한다. +이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다. + +{{< warning >}} +이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다. +{{< /warning >}} ## 클라우드 네이티브 보안의 4C -계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. + +보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), +클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다. + {{< note >}} 이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 -널리 알려져 있다. 4C는 클라우드(Cloud), 클러스터(Clusters), 컨테이너(Containers) 및 코드(Code)이다. +컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 +널리 알려져 있다. {{< /note >}} {{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}} - -위 그림에서 볼 수 있듯이, -4C는 각각의 사각형의 보안에 따라 다르다. 코드 -수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 -보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 -처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 -강화될 것이다. 이러한 관심 분야는 아래에서 더 자세히 설명한다. +클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다. +코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. +코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을 +보호할 수 없다. ## 클라우드 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 [신뢰 컴퓨팅 기반(trusted computing base)](https://en.wikipedia.org/wiki/Trusted_computing_base) -이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) -경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 -실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 -안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 -제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 -클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 -알려진 클라우드 공급자의 보안 문서의 일부와 -쿠버네티스 클러스터를 구성하기 위한 인프라 -보안에 대한 일반적인 지침을 제공한다. +이다. 클라우드 계층이 취약하거나 취약한 방식으로 +구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는 +보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 +위한 보안 권장 사항을 제시한다. -### 클라우드 공급자 보안 표 +### 클라우드 공급자 보안 +자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우, +보안 모범 사례는 설명서를 참고한다. +다음은 인기있는 클라우드 공급자의 보안 문서 중 일부에 대한 링크이다. +{{< table caption="클라우드 공급자 보안" >}} IaaS 공급자 | 링크 | -------------------- | ------------ | @@ -64,43 +58,46 @@ IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +{{< /table >}} -자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 -모범 사례는 해당 문서를 참조한다. +### 인프라스트럭처 보안 {#infrastructure-security} -### 일반적인 인프라 지침 표 +쿠버네티스 클러스터에서 인프라 보안을 위한 제안은 다음과 같다. + +{{< table caption="인프라스트럭처 보안" >}} 쿠버네티스 인프라에서 고려할 영역 | 추천 | --------------------------------------------- | ------------ | -API 서버에 대한 네트워크 접근(마스터) | 이상적으로는 인터넷에서 쿠버네티스 마스터에 대한 모든 접근을 공개적으로 허용하지 않으며 클러스터를 관리하는데 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록(ACL)에 의해 제어되어야 한다. | -노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. -클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 마스터 및 노드에 서로 다른 권한을 부여해야 함으로써, 이런 권장 사항이 더 일반적이다. 관리해야 하는 리소스에 대한 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. AWS의 Kops에 대한 예제: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles -etcd에 대한 접근 | etcd (쿠버네티스의 데이터저장소)에 대한 접근은 마스터로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 정보: https://github.com/etcd-io/etcd/tree/master/Documentation#security -etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화 하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 디스크의 암호화는 유휴 상태에서 암호화 되어야 한다. +API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다. | +노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. +클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다. +etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다. +etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다. + +{{< /table >}} ## 클러스터 -이 섹션에서는 쿠버네티스의 워크로드 -보안을 위한 링크를 제공한다. 쿠버네티스 -보안에 영향을 미치는 다음 두 가지 영역이 있다. +쿠버네티스 보안에는 다음의 두 가지 영역이 있다. -* 클러스터를 구성하는 설정 가능한 컴포넌트의 보안 -* 클러스터에서 실행되는 컴포넌트의 보안 +* 설정 가능한 클러스터 컴포넌트의 보안 +* 클러스터에서 실행되는 애플리케이션의 보안 -### 클러스터_의_ 컴포넌트 +### 클러스터의 컴포넌트 {#cluster-components} 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, 모범 사례에 대한 정보를 채택하기 위해서는 [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대한 조언을 읽고 따른다. -### 클러스터 _내_ 컴포넌트(애플리케이션) +### 클러스터 내 컴포넌트(애플리케이션) {#cluster-applications} + 애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, -리소스 제한을 설정하지 않은 서비스 B에 의해 -서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 -실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다. +서비스 B의 리소스를 제한하지 않으면 +서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서 +실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다. 워크로드 보안에서 고려할 영역 | 추천 | ------------------------------ | ------------ | @@ -112,51 +109,45 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/ 쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls - - ## 컨테이너 -쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, -쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 -반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 -또한 이 가이드의 범위를 벗어나지만, 해당 주제에 대한 추가적인 설명을 위하여 -일반 권장사항 및 링크 표를 아래에 제공한다. +컨테이너 보안은 이 가이드의 범위를 벗어난다. 다음은 일반적인 권장사항과 +이 주제에 대한 링크이다. 컨테이너에서 고려할 영역 | 추천 | ------------------------------ | ------------ | -컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부 또는 정기적으로 [CoreOS의 Clair](https://github.com/coreos/clair/)와 같은 도구를 사용해서 컨테이너에 알려진 취약점이 있는지 검사한다. -이미지 서명 및 시행 | 두 개의 다른 CNCF 프로젝트(TUF 와 Notary)는 컨테이너 이미지에 서명하고 컨테이너 내용에 대한 신뢰 시스템을 유지하는데 유용한 도구이다. 도커를 사용하는 경우 도커 엔진에 [도커 컨텐츠 신뢰](https://docs.docker.com/engine/security/trust/content_trust/)가 내장되어 있다. 시행 부분에서의 [IBM의 Portieris](https://github.com/IBM/portieris) 프로젝트는 쿠버네티스 다이나믹 어드미션 컨트롤러로 실행되는 도구로, 클러스터에서 허가하기 전에 Notary를 통해 이미지가 적절하게 서명되었는지 확인한다. +컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다. +이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다. 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다. ## 코드 -마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 -주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 -밖이지만 몇 가지 권장사항이 있다. +애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다. +애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만, +애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같다. -### 일반적인 코드 보안 지침표 +### 코드 보안 + +{{< table caption="코드 보안" >}} 코드에서 고려할 영역 | 추천 | ---------------------------------------------- | ------------ | -TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이언트와 먼저 TLS 핸드 셰이크를 수행하는 것이 이상적이다. 몇 가지 경우를 제외하고, 기본 동작은 전송 중인 모든 것을 암호화하는 것이다. 한걸음 더 나아가, VPC의 "방화벽 뒤"에서도 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. 이것을 수행하기 위해 쿠버네티스에는 [Linkerd](https://linkerd.io/) 및 [Istio](https://istio.io/)와 같은 수많은 도구가 있다. | +-------------------------| -------------- | +TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | -타사 종속성 보안 | 애플리케이션은 자체 코드베이스의 외부에 종속적인 경향이 있기 때문에, 코드의 종속성을 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | +타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | 정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | -동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://owasp.org/www-project-zap/ | - - -## 강력한(robust) 자동화 - -위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 -전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 -"지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. +동적 탐지 공격 | 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 여기에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 [OWASP Zed Attack 프록시](https://owasp.org/www-project-zap/)이다. | +{{< /table >}} ## {{% heading "whatsnext" %}} -* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) 알아보기 -* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기 -* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기 -* 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 -* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 -* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 +쿠버네티스 보안 주제에 관련한 내용들을 배워보자. + +* [파드 보안 표준](/docs/concepts/security/pod-security-standards/) +* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) +* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) +* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/) +* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) +* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) +* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/) diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index ad5b1f9bbb..be39f13f21 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -2,27 +2,28 @@ title: HostAliases로 파드의 /etc/hosts 항목 추가하기 content_type: concept weight: 60 +min-kubernetes-server-version: 1.7 --- -{{< toc >}} -파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. -HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. +파드의 `/etc/hosts` 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. + +HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. ## 기본 호스트 파일 내용 -파드 IP가 할당된 Nginx 파드를 시작해보자. +파드 IP가 할당된 Nginx 파드를 시작한다. ```shell -kubectl run nginx --image nginx --generator=run-pod/v1 +kubectl run nginx --image nginx ``` -```shell +``` pod/nginx created ``` @@ -32,7 +33,7 @@ pod/nginx created kubectl get pods --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` @@ -43,7 +44,7 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0 kubectl exec nginx -- cat /etc/hosts ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -57,43 +58,44 @@ fe00::2 ip6-allrouters 기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 상용구들만 포함하고 있다. -## HostAliases를 사용하여 추가 항목들 추가하기 +## hostAliases를 사용하여 추가 항목들 추가하기 -기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, -`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록 -추가 항목들을 `hosts` 파일에 추가할 수 있으며, -이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다. +기본 상용구 이외에, 추가 항목들을 `hosts` 파일에 +추가할 수 있다. +예를 들어, `foo.local`, `bar.local`이 `127.0.0.1`로, +`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록, `.spec.hostAliases` 항목에서 정의하여 파드에 +HostAliases를 추가하면 가능하다. {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -이 파드는 다음의 명령어를 통해 시작될 수 있다. +다음을 실행하여 해당 구성으로 파드를 실행할 수 있다. ```shell -kubectl apply -f hostaliases-pod.yaml +kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` -```shell +``` pod/hostaliases-pod created ``` -파드의 IP와 상태를 확인해보자. +파드의 세부 정보를 검토하여 IPv4 주소와 상태를 확인해보자. ```shell kubectl get pod --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 ``` -`hosts` 파일 내용은 아래와 같을 것이다. +`hosts` 파일 내용은 아래와 같다. ```shell -kubectl exec hostaliases-pod -- cat /etc/hosts +kubectl logs hostaliases-pod ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -110,14 +112,16 @@ fe00::2 ip6-allrouters 가장 마지막에 추가 항목들이 정의되어 있는 것을 확인할 수 있다. -## 왜 Kubelet이 호스트 파일을 관리하는가? +## 왜 Kubelet이 호스트 파일을 관리하는가? {#why-does-kubelet-manage-the-hosts-file} 컨테이너가 이미 시작되고 난 후 도커가 파일을 [수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 [관리](https://github.com/kubernetes/kubernetes/issues/14633)한다. -호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 -`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이 -덮어 쓰인다. 따라서, 호스트 파일의 내용을 -직접 바꾸는 것은 권장하지 않는다. +{{< caution >}} +컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다. + +호스트 파일을 수동으로 변경하면, +컨테이너가 종료되면 변경 사항이 손실된다. +{{< /caution >}} diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index eda8ab3d68..1993fc860d 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -50,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)을 자세히 읽어본다. +만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. ## 서비스 생성하기 @@ -198,7 +198,7 @@ kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m ``` 이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP -에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/docs/tasks/administer-cluster/coredns/#installing-coredns)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다. +에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/ko/docs/tasks/administer-cluster/coredns/#coredns-설치)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다. ```shell kubectl run curl --image=radial/busyboxplus:curl -i --tty @@ -422,5 +422,3 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el * [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다. * [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다. * [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다. - - diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index d07b03ea5d..d5f7a2abf3 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -41,7 +41,7 @@ term_id="selector" >}} 가 지정되면 EndpointSlice 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는 고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다. EndpointSlice 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice 리소스 샘플이 있다. @@ -180,4 +180,3 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) * [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 - diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 19982fd447..1a6de81950 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -18,7 +18,7 @@ weight: 40 * 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. * 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. * 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. -* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. * 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? @@ -79,8 +79,8 @@ spec: 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 인그레스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. -설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다. 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다. @@ -547,4 +547,3 @@ Events: * [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) - diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 51845e9496..4779d0504c 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -72,7 +72,7 @@ _서비스_ 로 들어가보자. 마찬가지로, 서비스 정의를 API 서버에 `POST`하여 새 인스턴스를 생성할 수 있다. 서비스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 예를 들어, 각각 TCP 포트 9376에서 수신하고 `app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자. @@ -168,7 +168,7 @@ subsets: ``` 엔드포인트 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. {{< note >}} 엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는 @@ -272,7 +272,7 @@ kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드 다르다. 해당 시나리오에서는, kube-proxy는 첫 번째 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다. -파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여 +파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여 백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는 정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다. @@ -418,7 +418,7 @@ DNS 만 사용하여 서비스의 클러스터 IP를 검색하는 경우, 이 ### DNS -[애드-온](/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스 +[애드-온](/ko/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스 클러스터의 DNS 서비스를 설정할 수(대개는 필수적임) 있다. CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위해 쿠버네티스 API를 감시하고 @@ -1094,7 +1094,7 @@ IP 주소를 정리한다. 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, 서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는 -iptables (Linux의 패킷 처리 로직)를 필요에 따라 +iptables (리눅스의 패킷 처리 로직)를 필요에 따라 명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. 환경 변수와 서비스 용 DNS는 실제로 서비스의 @@ -1176,7 +1176,7 @@ HTTP / HTTPS 서비스를 노출할 수도 있다. ### PROXY 프로토콜 -클라우드 공급자가 지원하는 경우에 (예: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), +클라우드 공급자가 지원하는 경우에 (예: [AWS](/ko/docs/concepts/cluster-administration/cloud-providers/#aws)), LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에 로드 밸런서를 구성할 수 있으며, 이때 접두사가 [PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다. @@ -1213,10 +1213,10 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n 클라우드 공급자의 로드 밸런서 구현이 프로토콜로서 SCTP를 지원하는 경우에만 LoadBalancer `유형`과 SCTP `프로토콜`을 사용하여 서비스를 생성할 수 있다. 그렇지 않으면, 서비스 생성 요청이 거부된다. 현재 클라우드 로드 밸런서 공급자 세트 (Azure, AWS, CloudStack, GCE, OpenStack)는 모두 SCTP에 대한 지원이 없다. {{< /warning >}} -##### Windows {#caveat-sctp-windows-os} +##### 윈도우 {#caveat-sctp-windows-os} {{< warning >}} -SCTP는 Windows 기반 노드를 지원하지 않는다. +SCTP는 윈도우 기반 노드를 지원하지 않는다. {{< /warning >}} ##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace} diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index c345a472fe..63892d11f4 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -277,7 +277,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다. 퍼시스턴트볼륨 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ```yaml apiVersion: v1 @@ -667,7 +667,7 @@ spec: {{< feature-state for_k8s_version="v1.17" state="beta" >}} -CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)을 참고한다. +CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참고한다. 볼륨 스냅샷 데이터 소스에서 볼륨 복원을 지원하려면 apiserver와 controller-manager에서 `VolumeSnapshotDataSource` 기능 게이트를 활성화한다. diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 13b4f49175..259a9a402b 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -34,9 +34,9 @@ weight: 30 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하며, 일단 생성된 오브젝트는 업데이트할 수 없다. -관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본 +관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본 스토리지클래스를 지정할 수 있다. 자세한 내용은 -[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#클래스-1)을 +[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)을 본다. ```yaml @@ -167,7 +167,7 @@ CSI | 1.14 (alpha), 1.16 (beta) [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector), [파드 어피니티(affinity)와 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) -그리고 [테인트(taint)와 톨러레이션(toleration)](/docs/concepts/configuration/taint-and-toleration/)이 포함된다. +그리고 [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)이 포함된다. 다음 플러그인은 동적 프로비저닝과 `WaitForFirstConsumer` 를 지원한다. @@ -251,11 +251,11 @@ parameters: * `iopsPerGB`: `io1` 볼륨 전용이다. 1초당 GiB에 대한 I/O 작업 수이다. AWS 볼륨 플러그인은 요청된 볼륨 크기에 곱셈하여 볼륨의 IOPS를 계산하고 이를 20,000 IOPS로 제한한다(AWS에서 지원하는 최대값으로, - [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다). + [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다). 여기에는 문자열, 즉 `10` 이 아닌, `"10"` 이 필요하다. * `fsType`: fsType은 쿠버네티스에서 지원된다. 기본값: `"ext4"`. * `encrypted`: EBS 볼륨의 암호화 여부를 나타낸다. - 유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열, + 유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열, 즉 `true` 가 아닌, `"true"` 가 필요하다. * `kmsKeyId`: 선택 사항. 볼륨을 암호화할 때 사용할 키의 전체 Amazon 리소스 이름이다. 아무것도 제공되지 않지만, `encrypted` 가 true라면 @@ -348,7 +348,7 @@ parameters: * `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할 사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는 선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면 - 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 + 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 하며, 예를 들어 다음과 같이 생성한다. ``` @@ -664,7 +664,7 @@ parameters: [RBAC](/docs/reference/access-authn-authz/rbac/)과 [컨트롤러의 롤(role)들](/docs/reference/access-authn-authz/rbac/#controller-roles)을 모두 활성화한 경우, clusterrole `system:controller:persistent-volume-binder` -에 대한 `secret` 리소스에 `create` 권한을 추가한다. +에 대한 `secret` 리소스에 `create` 권한을 추가한다. 다중 테넌시 컨텍스트에서 `secretNamespace` 의 값을 명시적으로 설정하는 것을 권장하며, 그렇지 않으면 다른 사용자가 스토리지 계정 자격증명을 @@ -688,16 +688,16 @@ parameters: * `fs`: 배치할 파일 시스템: `none/xfs/ext4` (기본값: `ext4`) * `block_size`: Kbytes 단위의 블록 크기(기본값: `32`). * `repl`: 레플리케이션 팩터 `1..3` (기본값: `1`)의 형태로 제공될 - 동기 레플리카의 수. 여기에는 문자열, + 동기 레플리카의 수. 여기에는 문자열, 즉 `0` 이 아닌, `"0"` 이 필요하다. * `io_priority`: 볼륨이 고성능 또는 우선 순위가 낮은 스토리지에서 생성될 것인지를 결정한다 `high/medium/low` (기본값: `low`). * `snap_interval`: 스냅샷을 트리거할 때의 시각/시간 간격(분). 스냅샷은 이전 스냅샷과의 차이에 따라 증분되며, 0은 스냅을 - 비활성화 한다(기본값: `0`). 여기에는 문자열, + 비활성화 한다(기본값: `0`). 여기에는 문자열, 즉 `70` 이 아닌, `"70"` 이 필요하다. * `aggregation_level`: 볼륨이 분배될 청크 수를 지정하며, 0은 집계되지 않은 - 볼륨을 나타낸다(기본값: `0`). 여기에는 문자열, + 볼륨을 나타낸다(기본값: `0`). 여기에는 문자열, 즉 `0` 이 아닌, `"0"` 이 필요하다. * `ephemeral`: 마운트 해제 후 볼륨을 정리해야 하는지 혹은 지속적이어야 하는지를 지정한다. `emptyDir` 에 대한 유스케이스는 이 값을 true로 @@ -815,4 +815,3 @@ volumeBindingMode: WaitForFirstConsumer 볼륨 바인딩을 지연시키면 스케줄러가 퍼시스턴트볼륨클레임에 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. - diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index cc31fae666..bdf1920567 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -6,7 +6,7 @@ weight: 30 -이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. +이 문서는 쿠버네티스의 볼륨스냅샷클래스(VolumeSnapshotClass) 개요를 설명한다. [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다. @@ -17,24 +17,21 @@ weight: 30 ## 소개 -`StorageClass` 는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 -설명하는 방법을 제공하는 것처럼, `VolumeSnapshotClass` 는 볼륨 스냅샷을 +스토리지클래스(StorageClass)는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 +설명하는 방법을 제공하는 것처럼, 볼륨스냅샷클래스는 볼륨 스냅샷을 프로비저닝할 때 스토리지의 "클래스"를 설명하는 방법을 제공한다. ## VolumeSnapshotClass 리소스 -각 `VolumeSnapshotClass` 에는 클래스에 속하는 `VolumeSnapshot` 을 +각 볼륨스냅샷클래스에는 클래스에 속하는 볼륨스냅샷을 동적으로 프로비전 할 때 사용되는 `driver`, `deletionPolicy` 그리고 `parameters` 필드를 포함한다. -`VolumeSnapshotClass` 오브젝트의 이름은 중요하며, 사용자가 특정 -클래스를 요청할 수 있는 방법이다. 관리자는 `VolumeSnapshotClass` 오브젝트를 +볼륨스냅샷클래스 오브젝트의 이름은 중요하며, 사용자가 특정 +클래스를 요청할 수 있는 방법이다. 관리자는 볼륨스냅샷클래스 오브젝트를 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가 생성된 이후에는 업데이트할 수 없다. -관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만 -기본 `VolumeSnapshotClass` 를 지정할 수 있다. - ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass @@ -45,6 +42,22 @@ deletionPolicy: Delete parameters: ``` +관리자는`snapshot.storage.kubernetes.io/is-default-class: "true"` 어노테이션을 추가하여 +바인딩할 특정 클래스를 요청하지 않는 볼륨스냅샷에 대한 +기본 볼륨스냅샷클래스를 지정할 수 있다. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + ### 드라이버 볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 @@ -52,9 +65,9 @@ parameters: ### 삭제정책(DeletionPolicy) -볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩 된 `VolumeSnapshot` 오브젝트를 삭제할 때 `VolumeSnapshotContent` 의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. +볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. -삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 `VolumeSnapshotContent` 모두 유지된다. +삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다. ## 파라미터 diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 997f3d6fee..9aadbe3726 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -7,7 +7,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.17" state="beta" >}} -쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. +쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. @@ -44,7 +44,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 -사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. +사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. ### 바인딩 @@ -82,7 +82,7 @@ spec: `persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. 볼륨 스냅샷은 `volumeSnapshotClassName` 속성을 사용하여 -[볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 +[볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 기본 클래스가 사용될 것이다. 사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다. @@ -145,6 +145,4 @@ spec: 스냅샷 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있다. 보다 자세한 사항은 -[볼륨 스냅샷 및 스냅샷에서 볼륨 복원](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)에서 확인할 수 있다. - - +[볼륨 스냅샷 및 스냅샷에서 볼륨 복원](/ko/docs/concepts/storage/persistent-volumes/#볼륨-스냅샷-및-스냅샷-지원에서-볼륨-복원)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index b8ff826d67..ce31b183a4 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -23,7 +23,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ## 배경 도커는 다소 느슨하고, 덜 관리되지만 -[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 +[볼륨](https://docs.docker.com/storage/)이라는 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 @@ -214,7 +214,7 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 {{< note >}} 전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자 -구성에 대해서는 [오픈스택 클라우드 공급자](/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. +구성에 대해서는 [오픈스택 클라우드 공급자](/ko/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. {{< /note >}} `cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 5917eb288d..c06a43edf6 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -54,7 +54,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). @@ -206,7 +206,7 @@ nodeAffinity: ### 스태틱(static) 파드 -Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 +Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다. 데몬셋과는 다르게 스태틱 파드는 kubectl 또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 269d72f510..91b20304c7 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -316,7 +316,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 `.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다. -결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다. +결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카셋은 0개로 스케일된다. 만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. @@ -671,7 +671,7 @@ deployment.apps/nginx-deployment scaled 디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다. 만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다. 비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다. -비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카 셋으로 이동한다. +비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카셋으로 이동한다. 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다. 위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. @@ -861,7 +861,12 @@ 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 $? +``` +그리고 `kubectl rollout` 의 종료 상태는 0(success)이다. +```shell +echo $? +``` +``` 0 ``` @@ -1003,7 +1008,12 @@ 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 $? +``` +그리고 `kubectl rollout` 의 종료 상태는 1(error를 의미함)이다. +```shell +echo $? +``` +``` 1 ``` @@ -1026,7 +1036,7 @@ $ echo $? ## 카나리 디플로이먼트 만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 -[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 +[리소스 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#카나리-canary-디플로이먼트)에 설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. ## 디플로이먼트 사양 작성 @@ -1035,7 +1045,7 @@ $ echo $? 설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index 4f4762fe9d..03083b86ed 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,7 +1,7 @@ --- title: 가비지(Garbage) 수집 content_type: concept -weight: 60 +weight: 70 --- @@ -10,8 +10,6 @@ weight: 60 소유자가 없는 오브젝트들을 삭제하는 역할을 한다. - - ## 소유자(owner)와 종속(dependent) @@ -170,15 +168,9 @@ kubectl delete replicaset my-repset --cascade=false - ## {{% heading "whatsnext" %}} [디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) - - - - - diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/job.md similarity index 100% rename from content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md rename to content/ko/docs/concepts/workloads/controllers/job.md diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index e99bb4f7c5..18c618a6b1 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. 레플리카셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다. @@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. -템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인 +템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다. ### 파드 셀렉터 @@ -250,7 +250,7 @@ matchLabels: 그렇지 않으면 API에 의해 거부된다. {{< note >}} -2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다. +2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다. {{< /note >}} ### 레플리카 @@ -307,7 +307,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron ### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정 -레플리카 셋은 +레플리카셋은 [Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다. 즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다. 다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다. @@ -316,7 +316,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스 클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는 -오토스케일 레플리카 셋 HPA가 생성된다. +오토스케일 레플리카셋 HPA가 생성된다. ```shell kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml @@ -361,5 +361,3 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에 설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다. 따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 7f78c8d6f0..53ff69b288 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -114,7 +114,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다. 레플리케이션 컨트롤러 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/). 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다. @@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. @@ -255,7 +255,7 @@ API 오브젝트에 대한 더 자세한 것은 [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다. 이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. -사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. +사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. ### 디플로이먼트 (권장되는) diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 39836fd7a1..06cdbdc5e3 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -25,7 +25,7 @@ weight: 40 위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. 만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, -삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 +삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index de92b4f3ea..99d274a00d 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,7 +1,7 @@ --- title: 완료된 리소스를 위한 TTL 컨트롤러 content_type: concept -weight: 65 +weight: 70 --- @@ -10,7 +10,7 @@ weight: 65 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 -[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만 +{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. @@ -29,7 +29,7 @@ kube-apiserver와 kube-controller-manager와 함께 ## TTL 컨트롤러 현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는 -[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) +[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리) 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다. 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index d29cc514e3..10baf43a7c 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -62,7 +62,7 @@ weight: 40 다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다. * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. -* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. +* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 리눅스 네임스페이스를 사용한다. 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다. * 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 18f4b3e813..470970f284 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,7 +77,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 -[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. +[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. 핸들러에는 다음과 같이 세 가지 타입이 있다. * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) @@ -406,4 +406,3 @@ spec: - diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index f1f586f5d8..8a81e708dd 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -198,7 +198,7 @@ spec: `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, -레플리카 셋 또는 스테이트풀셋에서 계산한다. +레플리카셋 또는 스테이트풀셋에서 계산한다. 예시 구성은 다음과 같다. diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index 05de1ccb61..e3464ff5cf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -29,7 +29,7 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만, 도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다. -파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및 +파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. 파드의 컨텍스트 내에서 개별 응용 프로그램은 추가적으로 하위 격리가 적용된다. @@ -180,7 +180,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다. 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다. -기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). +기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다. ### 파드 강제 삭제 diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 8f9ef72ba6..fb87ebeed6 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -12,7 +12,7 @@ card: -이 웹사이트는 [쿠버네티스 SIG Docs](/docs/contribute/#get-involved-with-sig-docs)에 의해서 관리됩니다. +이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다. 쿠버네티스 문서 기여자들은 @@ -35,7 +35,7 @@ card: 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. 2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -3. [풀 리퀘스트 열기](/docs/contribute/new-content/new-content/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. +3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 @@ -43,16 +43,16 @@ card: ## 첫 번째 기여 -- [기여 개요](/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. +- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. - [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. -- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. -- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. +- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. +- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다. - 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. - [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. ## 다음 단계 -- 리포지터리의 [로컬 복제본에서 작업](/docs/contribute/new-content/new-content/#fork-the-repo)하는 방법을 배워봅니다. +- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 방법을 배워봅니다. - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다. - [SIG Docs](/ko/docs/contribute/participating/)에 참여하고, [멤버 또는 검토자](/ko/docs/contribute/participating/#역할과-책임)가 되어봅니다. - [현지화](/ko/docs/contribute/localization_ko/)를 시작하거나 도와줍니다. diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 3f30f6eff9..2c4163ab47 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -39,6 +39,7 @@ PR 랭글러의 임무는 다음과 같다. - 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다. - 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다. - PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다. + - 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다. - 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다. ## 랭글러에게 유용한 GitHub 쿼리 diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 46439d3565..3c535edda7 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -217,21 +217,39 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. -website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. +website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo 컨테이너" %}} +{{< note >}} +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다. +{{< /note >}} + 1. 로컬에서 이미지를 빌드한다. ```bash make docker-image + # docker 사용(기본값) + make container-image + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-image ``` 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. ```bash make docker-serve + # docker 사용(기본값) + make container-serve + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-serve ``` 3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 @@ -286,7 +304,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. -또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)를 참고한다. +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. ### 로컬에서 피드백 해결 @@ -481,5 +499,3 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 - 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. - - diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index a1897f350c..0b4c34aee8 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -36,7 +36,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. ## 역할과 책임 -- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. +- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. - 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. - SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 @@ -62,7 +62,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다. {{< /note >}} -[CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)) 후에 누구나 다음을 할 수 있다. +[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. ## 멤버 @@ -224,7 +224,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. - 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 -것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) +것으로 기대한다. [일주일 간 PR Wrangler 되기](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 문서를 참고한다. ## SIG Docs 의장 @@ -299,7 +299,7 @@ PR 소유자에게 조언하는데 활용된다. - 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. - SIG Docs 승인자들만이 코멘트에 `/approve` 를 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 - [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 또는 [SIG Docs 의장](#sig-docs-의장)과 + [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과 같은 특정 역할도 수행한다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index 06c2b81f21..ca3d38a752 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -17,7 +17,7 @@ weight: 10 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. -- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다. +- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다. @@ -44,7 +44,7 @@ weight: 10 표시된다. 2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. - - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. - `size/`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. @@ -94,5 +94,3 @@ weight: 10 ### 기타 오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. - - diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index ac7252a50f..a2a36ee0c8 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -55,30 +55,30 @@ YAML 블록이다. 여기 예시가 있다. title: HTTP 프록시를 사용하여 쿠버네티스 API에 접근 --- -## 디렉토리 선택 +## 디렉터리 선택 -페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉토리에 넣자. +페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉터리에 넣자. * /content/en/docs/tasks/ * /content/en/docs/tutorials/ * /content/en/docs/concepts/ -파일을 기존 하위 디렉토리에 넣거나 새 하위 디렉토리에 +파일을 기존 하위 디렉터리에 넣거나 새 하위 디렉터리에 넣을 수 있다. ## 목차에 항목 배치 -목차는 문서 소스의 디렉토리 구조를 사용하여 -동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을 -생성하고, 하위 디렉토리는 각각 목차에 항목을 +목차는 문서 소스의 디렉터리 구조를 사용하여 +동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉터리는 최상위 레벨 탐색 기능을 +생성하고, 하위 디렉터리는 각각 목차에 항목을 갖는다. -각 하위 디렉토리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉토리의 컨텐츠에 대한 +각 하위 디렉터리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉터리의 컨텐츠에 대한 "홈" 페이지를 나타낸다. `_index.md`에는 템플릿이 필요없다. 그것은 -하위 디렉토리의 항목에 대한 개요 내용을 포함할 수 있다. +하위 디렉터리의 항목에 대한 개요 내용을 포함할 수 있다. -디렉토리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의 -최적의 순서가 아니다. 하위 디렉토리에서 항목의 상대적 정렬을 제어하려면 +디렉터리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의 +최적의 순서가 아니다. 하위 디렉터리에서 항목의 상대적 정렬을 제어하려면 `가중치:` 전문의 키를 정수로 설정하자. 일반적으로 우리는 나중에 항목을 추가하기 위해 10의 배수를 사용한다. 예를 들어 가중치가 `10`인 항목은 가중치가 `20`인 항목보다 우선한다. @@ -112,13 +112,13 @@ YAML 블록이다. 여기 예시가 있다. 샘플 YAML 파일을 포함시키려면 이 방법을 사용하자. YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때 -`/examples/` 의 하위 디렉토리 중 하나에 코드를 배치하자. 여기서 ``은 +`/examples/` 의 하위 디렉터리 중 하나에 코드를 배치하자. 여기서 ``은 주제에 관한 언어이다. 문서 파일에서 `codenew` 단축 코드(shortcode)를 사용하자. ```none {{/my-example-yaml>" */>}} ``` -여기서 `` 는 `examples` 디렉토리와 관련하여 포함될 +여기서 `` 는 `examples` 디렉터리와 관련하여 포함될 파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 `/content/en/examples/pods/storage/gce-volume.yaml` 에 있는 YAML 파일을 참조한다. @@ -135,7 +135,7 @@ YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때 ## 구성 파일에서 API 오브젝트를 작성하는 방법 표시 구성 파일을 기반으로 API 오브젝트를 생성하는 방법을 보여주려면 -`/examples` 아래의 하위 디렉토리 중 하나에 +`/examples` 아래의 하위 디렉터리 중 하나에 구성 파일을 배치하자. 문서에서 이 명령을 띄워보자. @@ -145,18 +145,18 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ``` {{< note >}} -`/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이 +`/examples` 디렉터리에 새 YAMl 파일을 추가할 때 파일이 `/examples_test.go` 파일에도 포함되어 있는지 확인하자. 웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로 실행하여 모든 예제가 테스트를 통과하도록 한다. {{< /note >}} 이 기술을 사용하는 문서의 예로 -[단일 인스턴스 스테이트풀 어플리케이션 실행](/docs/tutorials/stateful-application/run-stateful-application/)을 참조하자. +[단일 인스턴스 스테이트풀 어플리케이션 실행](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)을 참조하자. ## 문서에 이미지 추가 -이미지 파일을 `/images` 디렉토리에 넣는다. 기본 +이미지 파일을 `/images` 디렉터리에 넣는다. 기본 이미지 형식은 SVG 이다. @@ -164,5 +164,4 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ## {{% heading "whatsnext" %}} * [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기. -* [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. - +* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/new-content/)에 대해 알아보기. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index b47bbf5c14..20377994f1 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -57,6 +57,8 @@ cards: - name: release-notes title: 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. + button: "쿠버네티스 다운로드" + button_path: "/docs/setup/release/notes" - name: about title: 문서에 대하여 description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md new file mode 100644 index 0000000000..0639d05b15 --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -0,0 +1,5 @@ +--- +title: 커맨드 라인 도구 레퍼런스 +weight: 60 +toc-hide: true +--- diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md new file mode 100644 index 0000000000..1d344c0cb5 --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -0,0 +1,518 @@ +--- +weight: 10 +title: 기능 게이트 +content_type: concept +--- + + +이 페이지에는 관리자가 다른 쿠버네티스 컴포넌트에서 지정할 수 있는 다양한 +기능 게이트에 대한 개요가 포함되어 있다. + +기능의 단계(stage)에 대한 설명은 [기능 단계](#기능-단계)를 참고한다. + + + +## 개요 + +기능 게이트는 쿠버네티스 기능을 설명하는 일련의 키=값 쌍이다. +각 쿠버네티스 컴포넌트에서 `--feature-gates` 커맨드 라인 플래그를 사용하여 +이러한 기능을 켜거나 끌 수 있다. + + +각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을 +활성화 또는 비활성화할 수 있다. +모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다. +kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. + +```shell +--feature-gates="...,DynamicKubeletConfig=true" +``` + +다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 +요약한 것이다. + +- "도입" 열에는 기능이 소개되거나 릴리스 단계가 변경될 때의 + 쿠버네티스 릴리스가 포함된다. +- "종료" 열이 비어 있지 않으면, 여전히 기능 게이트를 사용할 수 있는 마지막 + 쿠버네티스 릴리스가 포함된다. +- 기능이 알파 또는 베타 상태인 경우, + [알파/베타 기능 게이트 테이블](#알파-또는-베타-기능을-위한-기능-게이트)에서 나열된 기능을 찾을 수 있다. +- 기능이 안정된 경우 해당 기능에 대한 모든 단계를 + [GA(graduated)/사용 중단(deprecated) 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에 나열할 수 있다. +- [GA/사용 중단 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에는 + 사용 중단된 기능과 철회(withdrawn) 기능의 목록도 있다. + +### 알파 또는 베타 기능을 위한 기능 게이트 + +{{< table caption="알파 또는 베타 단계에 있는 기능을 위한 기능 게이트" >}} + +| 기능 | 디폴트 | 단계 | 도입 | 종료 | +|---------|---------|-------|-------|-------| +| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | +| `APIListChunking` | `false` | 알파 | 1.8 | 1.8 | +| `APIListChunking` | `true` | 베타 | 1.9 | | +| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | | +| `APIResponseCompression` | `false` | 알파 | 1.7 | | +| `AppArmor` | `true` | 베타 | 1.4 | | +| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | | +| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | | +| `CPUManager` | `false` | 알파 | 1.8 | 1.9 | +| `CPUManager` | `true` | 베타 | 1.10 | | +| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | +| `CRIContainerLogRotation` | `true` | 베타| 1.11 | | +| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | +| `CSIInlineVolume` | `true` | 베타 | 1.16 | - | +| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigration` | `true` | 베타 | 1.17 | | +| `CSIMigrationAWS` | `false` | 알파 | 1.14 | | +| `CSIMigrationAWS` | `false` | 베타 | 1.17 | | +| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigrationGCE` | `false` | 베타 | 1.17 | | +| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | | +| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | | +| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | | +| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | +| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | +| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | | +| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | +| `DevicePlugins` | `true` | 베타 | 1.10 | | +| `DryRun` | `false` | 알파 | 1.12 | 1.12 | +| `DryRun` | `true` | 베타 | 1.13 | | +| `DynamicAuditing` | `false` | 알파 | 1.13 | | +| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | | +| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | +| `EndpointSlice` | `false` | 베타 | 1.17 | | +| `EndpointSlice` | `true` | 베타 | 1.18 | | +| `EndpointSliceProxying` | `false` | 알파 | 1.18 | | +| `EphemeralContainers` | `false` | 알파 | 1.16 | | +| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | +| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | | +| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 | +| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | | +| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | +| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | | +| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | +| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | 베타 | 1.18 | | +| `HPAScaleToZero` | `false` | 알파 | 1.16 | | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | | +| `HyperVContainer` | `false` | 알파 | 1.10 | | +| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | | +| `IPv6DualStack` | `false` | 알파 | 1.16 | | +| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | +| `KubeletPodResources` | `true` | 베타 | 1.15 | | +| `LegacyNodeRoleBehavior` | `true` | 알파 | 1.16 | | +| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | +| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | +| `MountContainers` | `false` | 알파 | 1.9 | | +| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | | +| `NonPreemptingPriority` | `false` | 알파 | 1.15 | | +| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | 베타 | 1.5 | | +| `PodOverhead` | `false` | 알파 | 1.16 | - | +| `ProcMountType` | `false` | 알파 | 1.12 | | +| `QOSReserved` | `false` | 알파 | 1.11 | | +| `RemainingItemCount` | `false` | 알파 | 1.15 | | +| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | | +| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | | +| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | +| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | +| `RunAsGroup` | `true` | 베타 | 1.14 | | +| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | +| `RuntimeClass` | `true` | 베타 | 1.14 | | +| `SCTPSupport` | `false` | 알파 | 1.12 | | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | | +| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | +| `ServerSideApply` | `true` | 베타 | 1.16 | | +| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | | +| `ServiceTopology` | `false` | 알파 | 1.17 | | +| `StartupProbe` | `false` | 알파 | 1.16 | | +| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | +| `StorageVersionHash` | `true` | 베타 | 1.15 | | +| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | +| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | | +| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 | +| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | | +| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | +| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | | +| `Sysctls` | `true` | 베타 | 1.11 | | +| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 | +| `TokenRequest` | `true` | 베타 | 1.12 | | +| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 | +| `TokenRequestProjection` | `true` | 베타 | 1.12 | | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | | +| `TopologyManager` | `false` | 알파 | 1.16 | | +| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | +| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | | +| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | +| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - | +| `WindowsGMSA` | `false` | 알파 | 1.14 | | +| `WindowsGMSA` | `true` | 베타 | 1.16 | | +| `WinDSR` | `false` | 알파 | 1.14 | | +| `WinOverlay` | `false` | 알파 | 1.14 | | +{{< /table >}} + +### GA 또는 사용 중단된 기능을 위한 기능 게이트 + +{{< table caption="GA 또는 사용 중단 기능을 위한 기능 게이트" >}} + +| 기능 | 디폴트 | 단계 | 도입 | 종료 | +|---------|---------|-------|-------|-------| +| `Accelerators` | `false` | 알파 | 1.6 | 1.10 | +| `Accelerators` | - | 사용 중단 | 1.11 | - | +| `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 | +| `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 | +| `AdvancedAuditing` | `true` | GA | 1.12 | - | +| `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | +| `AffinityInAnnotations` | - | 사용 중단 | 1.8 | - | +| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | +| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | +| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | +| `BlockVolume` | `true` | GA | 1.18 | - | +| `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 | +| `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 | +| `CSIBlockVolume` | `true` | GA | 1.18 | - | +| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | +| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | +| `CSIDriverRegistry` | `true` | GA | 1.18 | | +| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | +| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | +| `CSINodeInfo` | `true` | GA | 1.17 | | +| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | +| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | +| `AttachVolumeLimit` | `true` | GA | 1.17 | - | +| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 | +| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 | +| `CSIPersistentVolume` | `true` | GA | 1.13 | - | +| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | +| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | +| `CustomPodDNS` | `true` | GA | 1.14 | - | +| `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 | +| `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 | +| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - | +| `CustomResourceSubresources` | `false` | 알파 | 1.10 | 1.10 | +| `CustomResourceSubresources` | `true` | 베타 | 1.11 | 1.15 | +| `CustomResourceSubresources` | `true` | GA | 1.16 | - | +| `CustomResourceValidation` | `false` | 알파 | 1.8 | 1.8 | +| `CustomResourceValidation` | `true` | 베타 | 1.9 | 1.15 | +| `CustomResourceValidation` | `true` | GA | 1.16 | - | +| `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | +| `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | +| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | +| `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - | +| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | +| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | +| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - | +| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | +| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - | +| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | +| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | +| `HugePages` | `false` | 알파 | 1.8 | 1.9 | +| `HugePages` | `true` | 베타| 1.10 | 1.13 | +| `HugePages` | `true` | GA | 1.14 | - | +| `Initializers` | `false` | 알파 | 1.7 | 1.13 | +| `Initializers` | - | 사용 중단 | 1.14 | - | +| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | +| `KubeletConfigFile` | - | 사용 중단 | 1.10 | - | +| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | +| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | +| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | +| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | +| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | +| `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeLease` | `false` | 알파 | 1.12 | 1.13 | +| `NodeLease` | `true` | 베타 | 1.14 | 1.16 | +| `NodeLease` | `true` | GA | 1.17 | - | +| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | +| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | +| `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodPriority` | `false` | 알파 | 1.8 | 1.10 | +| `PodPriority` | `true` | 베타 | 1.11 | 1.13 | +| `PodPriority` | `true` | GA | 1.14 | - | +| `PodReadinessGates` | `false` | 알파 | 1.11 | 1.11 | +| `PodReadinessGates` | `true` | 베타 | 1.12 | 1.13 | +| `PodReadinessGates` | `true` | GA | 1.14 | - | +| `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 | +| `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | +| `PodShareProcessNamespace` | `true` | GA | 1.17 | - | +| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | +| `PVCProtection` | - | 사용 중단 | 1.10 | - | +| `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | +| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | +| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | +| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | +| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | +| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | +| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | +| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | +| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | +| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | +| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | +| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | +| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | +| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | +| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 | +| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 | +| `TaintBasedEvictions` | `true` | GA | 1.18 | - | +| `TaintNodesByCondition` | `false` | 알파 | 1.8 | 1.11 | +| `TaintNodesByCondition` | `true` | 베타 | 1.12 | 1.16 | +| `TaintNodesByCondition` | `true` | GA | 1.17 | - | +| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | +| `VolumePVCDataSource` | `true` | GA | 1.18 | - | +| `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | - | +| `VolumeSubpath` | `true` | GA | 1.13 | - | +| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 | +| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 | +| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - | +| `WatchBookmark` | `false` | 알파 | 1.15 | 1.15 | +| `WatchBookmark` | `true` | 베타 | 1.16 | 1.16 | +| `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 | +| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 | +| `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 | +| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 | +| `WindowsRunAsUserName` | `true` | GA | 1.18 | - | +{{< /table >}} + +## 기능 사용 + +### 기능 단계 + +기능은 *알파*, *베타* 또는 *GA* 단계일 수 있다. +*알파* 기능은 다음을 의미한다. + +* 기본적으로 비활성화되어 있다. +* 버그가 있을 수 있다. 이 기능을 사용하면 버그에 노출될 수 있다. +* 기능에 대한 지원은 사전 통지없이 언제든지 중단될 수 있다. +* API는 이후 소프트웨어 릴리스에서 예고없이 호환되지 않는 방식으로 변경될 수 있다. +* 버그의 위험이 증가하고 장기 지원이 부족하여, 단기 테스트 + 클러스터에서만 사용하는 것이 좋다. + +*베타* 기능은 다음을 의미한다. + +* 기본적으로 활성화되어 있다. +* 이 기능은 잘 테스트되었다. 이 기능을 활성화하면 안전한 것으로 간주된다. +* 세부 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다. +* 오브젝트의 스키마 및/또는 시맨틱은 후속 베타 또는 안정 릴리스에서 + 호환되지 않는 방식으로 변경될 수 있다. 이러한 상황이 발생하면, 다음 버전으로 마이그레이션하기 위한 + 지침을 제공한다. API 오브젝트를 삭제, 편집 및 재작성해야 + 할 수도 있다. 편집 과정에서 약간의 생각이 필요할 수 있다. + 해당 기능에 의존하는 애플리케이션의 경우 다운타임이 필요할 수 있다. +* 후속 릴리스에서 호환되지 않는 변경이 발생할 수 있으므로 + 업무상 중요하지 않은(non-business-critical) 용도로만 + 권장한다. 독립적으로 업그레이드할 수 있는 여러 클러스터가 있는 경우, 이 제한을 완화할 수 있다. + +{{< note >}} +*베타* 기능을 사용해 보고 의견을 보내주길 바란다! +베타 기간이 종료된 후에는, 더 많은 변경을 하는 것이 실용적이지 않을 수 있다. +{{< /note >}} + +*GA*(General Availability) 기능은 *안정* 기능이라고도 한다. 이 의미는 다음과 같다. + +* 이 기능은 항상 활성화되어 있다. 비활성화할 수 없다. +* 해당 기능 게이트는 더 이상 필요하지 않다. +* 여러 후속 버전의 릴리스된 소프트웨어에 안정적인 기능의 버전이 포함된다. + +## 기능 게이트 목록 {#feature-gates} + +각 기능 게이트는 특정 기능을 활성화/비활성화하도록 설계되었다. + +- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다. +- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다. +- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 설정을 활성화한다. +- `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. +- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의 + `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다. +- `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다. +- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 ​​있다. (`RequestManagement` 에서 이름이 변경됨) +- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다. +- `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다. + 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다. +- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 + 대한 제한을 보고하도록 한다. + 자세한 내용은 [동적 볼륨 제한](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)을 참고한다. +- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 + 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 + 더 가까운 노드가 선호된다. +- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. + 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 + 참고한다. +- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 + 마이그레이션한다. + 자세한 내용은 [서비스 어카운트 토큰 볼륨](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)을 + 확인한다. +- `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. +- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. +- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. +- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) 문서를 참고한다. +- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다. +- `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. +- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. +- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다. +- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. +- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) + 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 + 마운트할 수 있다. + 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. +- `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다. +- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. + 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 + 확인한다. +- `CustomResourceDefaulting`: OpenAPI v3 유효성 검사 스키마에서 기본값에 대한 CRD 지원을 활성화한다. +- `CustomResourcePublishOpenAPI`: CRD OpenAPI 사양을 게시할 수 있다. +- `CustomResourceSubresources`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 `/status` 및 `/scale` 하위 리소스를 활성화한다. +- `CustomResourceValidation`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. +- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. + 실행 중인 파드 문제를 해결한다. +- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/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`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의 [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다. +- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초 시간 초과를 활성화한다. +- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 동등성을 캐시할 수 있게 한다. +- `EphemeralContainers`: 파드를 실행하기 위한 {{< glossary_tooltip text="임시 컨테이너" + term_id="ephemeral-container" >}}를 추가할 수 있다. +- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다. +- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다. +- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다. +- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. + 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. +- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로 + 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, + 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 + 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 + 재 매핑이 활성화된 경우에만 활성화해야 한다. +- `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 + 엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, kube-proxy는 + 엔드포인트슬라이스를 엔드포인트 대신 기본 데이터 소스로 사용하여 + 확장성과 성능을 향상시킨다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. +- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다. +- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다. +- `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. +- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 `minReplicas` 를 0으로 설정한다. +- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. + 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. +- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 + 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. +- `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다. + 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다. +- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. +- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다. +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다. +- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. +- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. + 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. +- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. +- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. +- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 NonPreempting 옵션을 활성화한다. +- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. + `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. +- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/configuration/pod-overhead/) 기능을 활성화한다. +- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. +- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 + `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 + 참고한다. +- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 + 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 + [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. +- `ProcMountType`: 컨테이너의 ProcMountType 제어를 활성화한다. +- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 + 삭제되지 않도록 한다. +- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 + 요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당). +- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 + 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 + 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 + 노드 사이의 관계를 끊는 것이다. +- `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다. +- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. + 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. +- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. + 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. +- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. +- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다. +- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. +- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다. +- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. +- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. +- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. +- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. + "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다. +- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. +- `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. +- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 + 사용 중인 경우 삭제를 연기한다. +- `StorageVersionHash`: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록 허용한다. +- `StreamingProxyRedirects`: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을 + 가로채서 따르도록 API 서버에 지시한다. + 스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다. +- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. + 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. +- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. +- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. + 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. +- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. + 자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참고한다. +- `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을 기반으로 자동 테인트 노드를 활성화한다. +- `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다. +- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 서비스 어카운트 + 토큰을 파드에 주입할 수 있다. +- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다. +- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 실행이 끝난 후 리소스를 정리하도록 허용한다. +- `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다. +- `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고 + 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 + `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때 + [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다. +- `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다. +- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 `subPathExpr` 필드를 활성화한다. +- `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다. +- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. +- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다. + 자세한 내용은 [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을 참고한다. +- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다. +- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다. + + +## {{% heading "whatsnext" %}} + +* [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한 + 기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다. diff --git a/content/ko/docs/reference/glossary/cni.md b/content/ko/docs/reference/glossary/cni.md index a88ac5277a..28fc3602f3 100644 --- a/content/ko/docs/reference/glossary/cni.md +++ b/content/ko/docs/reference/glossary/cni.md @@ -2,17 +2,17 @@ title: 컨테이너 네트워크 인터페이스(Container network interface, CNI) id: cni date: 2018-05-25 -full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni short_description: > 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. -aka: +aka: tags: -- networking +- networking --- 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. - + -* 쿠버네티스와 CNI에 대한 정보는 [여기](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)를 참고한다. -* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)에서 볼 수 있다. +* 쿠버네티스와 CNI에 대한 정보는 [여기](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)를 참고한다. +* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)에서 볼 수 있다. diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index b0f8342b66..453bb6b652 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -11,9 +11,9 @@ tags: - core-object - workload --- - 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/job/)을 관리. -*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://en.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. +*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://ko.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index 85fe177e6b..4d7ec8debe 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -24,6 +24,6 @@ tags: 장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나, 각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다. -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 의 더 자세한 정보를 본다 diff --git a/content/ko/docs/reference/glossary/docker.md b/content/ko/docs/reference/glossary/docker.md index 64d264479d..4e0d7a305d 100755 --- a/content/ko/docs/reference/glossary/docker.md +++ b/content/ko/docs/reference/glossary/docker.md @@ -14,5 +14,5 @@ tags: -Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. +Docker는 리눅스 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 리눅스 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. diff --git a/content/ko/docs/reference/glossary/job.md b/content/ko/docs/reference/glossary/job.md index a2c5a83466..8f227f76ac 100755 --- a/content/ko/docs/reference/glossary/job.md +++ b/content/ko/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: 잡(Job) id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /docs/concepts/workloads/controllers/job short_description: > 완료를 목표로 실행되는 유한 또는 배치 작업. diff --git a/content/ko/docs/reference/glossary/minikube.md b/content/ko/docs/reference/glossary/minikube.md index 57267cddd4..f43966260e 100755 --- a/content/ko/docs/reference/glossary/minikube.md +++ b/content/ko/docs/reference/glossary/minikube.md @@ -17,5 +17,4 @@ tags: Minikube는 VM이나 사용자 컴퓨터에서 단일 노드 클러스터를 실행한다. Minikube를 사용하여 -[학습 환경에서 쿠버네티스 시도하기](/docs/setup/learning-environment/)를 할 수 있다. - +[학습 환경에서 쿠버네티스 시도하기](/ko/docs/setup/learning-environment/)를 할 수 있다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md index bbe78369a2..651b81d1d2 100755 --- a/content/ko/docs/reference/glossary/volume.md +++ b/content/ko/docs/reference/glossary/volume.md @@ -4,14 +4,14 @@ id: volume date: 2018-04-12 full_link: /ko/docs/concepts/storage/volumes/ short_description: > - 데이터를 포함하고 있는 디렉토리이며, 파드의 컨테이너에서 접근 가능하다. + 데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다. aka: tags: - core-object - fundamental --- - 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. + 데이터를 포함하고 있는 디렉터리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index bcf654b0bd..42d761ee93 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -255,7 +255,7 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 다른 편집기 사용 ## 리소스 스케일링 ```bash -kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카 셋을 3으로 스케일 +kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카셋을 3으로 스케일 kubectl scale --replicas=3 -f foo.yaml # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일 kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개의 레플리케이션 컨트롤러 스케일 @@ -286,6 +286,11 @@ kubectl logs -f my-pod # 실시간 스트림 파드 kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우) kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout) kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행 +kubectl run nginx --image=nginx -n +mynamespace # 특정 네임스페이스에서 nginx 파드 실행 +kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 +--dry-run=client -o yaml > pod.yaml + kubectl attach my-pod -i # 실행중인 컨테이너에 연결 kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) @@ -310,7 +315,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### 리소스 타입 -단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-groups)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: +단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: ```bash kubectl api-resources @@ -385,5 +390,3 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. * 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인 - - diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 0a4a3fefbe..cf835c5c5c 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -8,7 +8,7 @@ card: --- -Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. +Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. @@ -29,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags] * `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` @@ -110,13 +110,13 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -기억하기: 명령 동작에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. -(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치한다.) +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.) | 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 | |---|---|---|---|---| @@ -172,7 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -231,9 +231,9 @@ kubectl get pods -o custom-columns-file=template.txt NAME RSRC metadata.name metadata.resourceVersion ``` -두 명령 중 하나를 실행한 결과는 다음과 같다. +두 명령 중 하나를 실행한 결과는 다음과 비슷하다. -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -244,7 +244,7 @@ submit-queue 610995 이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다. 이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다. -이 기능은 기본적으로 `kubectl` 1.11 이상에서 활성화되어 있다. 사용하지 않으려면, +이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면, `kubectl get` 명령에 `--server-print=false` 플래그를 추가한다. ##### 예제 @@ -255,9 +255,9 @@ submit-queue 610995 kubectl get pods --server-print=false ``` -출력 결과는 다음과 같다. +출력 결과는 다음과 비슷하다. -```shell +``` NAME AGE pod-name 1m ``` @@ -402,16 +402,20 @@ cat service.yaml | kubectl diff -f - # 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로 # 시작하도록 실행 파일의 이름을 지정한다. cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # 이 플러그인은 "hello world"라는 단어를 출력한다 echo "hello world" - -# 작성한 플러그인을 실행 가능하게 한다 -sudo chmod +x ./kubectl-hello +``` +작성한 플러그인을 실행 가능하게 한다 +```bash +chmod a+x ./kubectl-hello # 그리고 PATH의 위치로 옮긴다 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin # 이제 kubectl 플러그인을 만들고 "설치했다". # kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다 @@ -422,16 +426,18 @@ hello world ``` ```shell -# PATH에서 플러그인 파일을 간단히 삭제하여, 플러그인을 "제거"할 수 있다 +# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여, +# 플러그인을 "제거"할 수 있다 sudo rm /usr/local/bin/kubectl-hello ``` `kubectl` 에 사용할 수 있는 모든 플러그인을 보려면, -`kubectl plugin list` 하위 명령을 사용할 수 있다. +`kubectl plugin list` 하위 명령을 사용한다. ```shell kubectl plugin list ``` +출력 결과는 다음과 비슷하다. ``` The following kubectl-compatible plugins are available: @@ -439,11 +445,11 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list` 는 또한 실행 가능하지 않거나, +다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다. ```shell -# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, -# 다른 플러그인에 의해 가려진 플러그인에 대해 -# 경고할 수 있다 -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거 kubectl plugin list ``` ``` @@ -462,6 +468,10 @@ error: one plugin warning was found ```shell cat ./kubectl-whoami +``` +다음 몇 가지 예는 이미 `kubectl-whoami` 에 +다음 내용이 있다고 가정한다. +```shell #!/bin/bash # 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한 @@ -469,7 +479,7 @@ cat ./kubectl-whoami kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재 선택된 컨텍스트에 대한 +위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한 사용자가 포함된 출력이 제공된다. ```shell @@ -483,11 +493,10 @@ kubectl whoami Current user: plugins-user ``` -플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. ## {{% heading "whatsnext" %}} -[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. - +* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. +* 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools.md index f9a9836bdc..ceac0a5101 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools.md @@ -12,7 +12,7 @@ content_type: concept ## Kubectl -[`kubectl`](/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다. ## Kubeadm @@ -20,7 +20,7 @@ content_type: concept ## Minikube -[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 +[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 쉽게 구동시키는 도구이다. @@ -51,4 +51,3 @@ Kompose의 용도 * 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환 * 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전 * V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환 - diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index 098e9ad9bf..d961283b99 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -78,9 +78,9 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. * *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다. * 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 - (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/docs/reference/)에서 확인할 수 있다. + (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다. -[사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. +[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. - 기본적인 CRUD 요구에는 [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) @@ -109,6 +109,3 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다. {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} - - - diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 321cf5ed2f..a0a87e0837 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -16,7 +16,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. 대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 -또는 [kubeconfig 파일](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) 포맷을 통해 +또는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 포맷을 통해 자격증명과 API 서버 주소를 읽을 수 있게 쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다. diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 21cd279764..098ed2c7ba 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -36,7 +36,7 @@ card: |커뮤니티 |생태계 | | ------------ | -------- | -| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [Minikube](/ko/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| @@ -46,5 +46,3 @@ card: 운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자. [쿠버네티스 파트너](https://kubernetes.io/partners/#conformance)에는 [공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자 목록이 포함되어 있다. - - diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index f5d1486f39..e152e378c5 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -36,7 +36,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. ## 인증서를 저장하는 위치 -만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉토리에 상대적이다. +만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다. ## 인증서 수동 설정 diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index df95e1dc5c..d29c8f49c2 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -12,9 +12,6 @@ weight: 20 * 전체 컨테이너 300000개 이하 * 노드 당 파드 100개 이하 -
- -{{< toc >}} ## 설치 @@ -112,7 +109,7 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 [#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자. -애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)을 참고하라. +애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라. [미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다. 이런 기능들에 대한 PR은 언제든 환영한다. diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 13bdaa04a9..2ccd3873a0 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -6,7 +6,7 @@ content_type: concept -이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다. +이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다. @@ -77,7 +77,7 @@ located in a single zone. Users that want a highly available control plane should follow the [high availability](/docs/admin/high-availability) instructions. ### Volume limitations -The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). +The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드). * StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with pod affinity or anti-affinity policies. @@ -396,5 +396,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c k KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` - - diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index 3aa27d96ea..d4579e2f89 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -3,7 +3,6 @@ title: 노드 구성 검증하기 weight: 30 --- -{{< toc >}} ## 노드 적합성 테스트 diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 7cc0eb9874..16ea2ad587 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -194,7 +194,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. 클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다. 이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다. -이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. +이 커멘드는 또한 [kubectl](/ko/docs/reference/kubectl/overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. {{< note >}} 웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. @@ -447,9 +447,9 @@ spec: | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | -| VirtualBox | Linux | /home | /hosthome | +| VirtualBox | 리눅스 | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | -| VirtualBox | Windows | C://Users | /c/Users | +| VirtualBox | 윈도우 | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | @@ -505,7 +505,7 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit * **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. * **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. * **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. -* **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. +* **MicroK8s**: 가상 머신을 사용하지 않으려는 리눅스 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index f14834ff25..39c2d07464 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -25,7 +25,7 @@ weight: 10 ### 적용 가능성 {{< note >}} -이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다. +이 문서는 리눅스에 CRI를 설치하는 사용자를 위해 작성되었다. 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. {{< /note >}} @@ -34,7 +34,7 @@ weight: 10 ### Cgroup 드라이버 -Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 +리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는 root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. 컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. @@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## 도커 각 머신들에 대해서, 도커를 설치한다. -버전 19.03.8이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.11이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 도커 버전의 지속적인 파악이 필요하다. 시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. @@ -94,9 +94,9 @@ add-apt-repository \ ```shell # 도커 CE 설치. apt-get update && apt-get install -y \ - containerd.io=1.2.13-1 \ - docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell @@ -142,8 +142,8 @@ yum-config-manager --add-repo \ # 도커 CE 설치. yum update -y && yum install -y \ containerd.io-1.2.13 \ - docker-ce-19.03.8 \ - docker-ce-cli-19.03.8 + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 ``` ```shell @@ -180,6 +180,12 @@ systemctl restart docker {{< /tab >}} {{< /tabs >}} +부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. + +```shell +sudo systemctl enable docker +``` + 자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/) 를 참고한다. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 29716b44e1..3fc7d975b7 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -9,7 +9,7 @@ weight: 20 이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다. [`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다. -kops는 자동화된 프로비저닝 시스템인데, +kops는 자동화된 프로비저닝 시스템인데, * 완전 자동화된 설치 * DNS를 통해 클러스터들의 신원 확인 @@ -23,7 +23,7 @@ kops는 자동화된 프로비저닝 시스템인데, ## {{% heading "prerequisites" %}} -* [kubectl](/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다. +* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다. * 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다. @@ -82,7 +82,7 @@ brew update && brew install kops ``` {{% /tab %}} -{{% tab name="Linux" %}} +{{% tab name="리눅스" %}} 최신 릴리즈를 다운로드 받는 명령어: @@ -127,7 +127,7 @@ brew update && brew install kops kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할 수 있다. -이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 +이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다. @@ -140,7 +140,7 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone `example.com`하위에는 그렇지 않을 수 있다). `dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자. -보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 +보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다. 그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, @@ -175,7 +175,7 @@ S3 버킷 이름으로 정하자. * `aws s3 mb s3://clusters.dev.example.com`를 이용해 S3 버킷을 생성한다. -* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. +* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. 이 부분을 bash profile등에 넣어두는것을 권장한다. @@ -185,7 +185,7 @@ S3 버킷 이름으로 정하자. `kops create cluster --zones=us-east-1c useast1.dev.example.com` -kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ +kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다. @@ -220,7 +220,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 ### 다른 애드온 탐험 -[애드온 리스트](/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다. +[애드온 리스트](/ko/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다. ## 정리하기 @@ -231,9 +231,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 ## {{% heading "whatsnext" %}} -* 쿠버네티스 [개념](/docs/concepts/) 과 [`kubectl`](/docs/user-guide/kubectl-overview/)에 대해 더 알아보기. +* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/overview/)에 대해 더 알아보기. * 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다. * 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues) - - diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index 359ec82a9c..6ce0119d9f 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -5,80 +5,15 @@ weight: 50 content_type: concept --- -{{< toc >}} - -쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 -보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 +쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 +보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. - - - -## 웹 UI (대시보드) - -쿠버네티스 클러스터에서 컨테이너화 된 애플리케이션을 관리 및 모니터하는 것을 돕기 위해서 대시보드 웹 유저 인터페이스를 디플로이하고 접속한다. - -## kubectl 커맨드라인 사용하기 - -쿠버네티스 클러스터를 직접 관리하기 위해서 사용되는 `kubectl` 커맨드라인 툴을 설치 및 설정한다. - -## 파드 및 컨테이너 구성하기 - -파드 및 컨테이너에 대한 일반적인 구성 태스크를 수행한다. - -## 애플리케이션 동작시키기 - -롤링 업데이트, 파드에 정보 주입하기, 파드 수평적 오토스케일링 등, 일반적인 애플리케이션 관리 태스크를 수행한다. - -## 잡 동작시키기 - -병렬 프로세싱을 사용하는 잡을 동작시킨다. - -## 클러스터의 애플리케이션에 접근하기 - -클러스터 내에 있는 애플리케이션에 접근할 수 있도록 로드 밸런싱, 포트 포워딩, 방화벽 또는 DNS 구성 등을 구성한다. - -## 모니터링, 로깅, 디버깅 - -클러스터 문제를 해결하거나 컨테이너화 된 애플리케이션을 디버깅하기 위해서 모니터링과 로깅을 설정한다. - -## 쿠버네티스 API에 접근하기 - -쿠버네티스 API에 직접 접근하는 다양한 방법을 배운다. - -## TLS 사용하기 - -클러스터 루트 인증 기관(CA)을 신뢰 및 사용하도록 애플리케이션을 구성한다. - -## 클러스터 운영하기(administering) - -클러스터를 운영하기 위한 일반적인 태스크를 배운다. - -## 스테이트풀 애플리케이션 관리하기 - -스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. - -## 클러스터 데몬 - -롤링 업데이트를 수행과 같은, 데몬 셋 관리를 위한 일반적인 태스크를 수행한다. - -## GPU 관리하기 - -클러스터의 노드들에 의해서 리소스로 사용될 NVIDIA GPU들을 구성 및 스케줄한다. - -## HugePage 관리하기 - -클러스터에서 스케줄 가능한 리소스로서 Huge Page들을 구성 및 스케줄한다. - - - ## {{% heading "whatsnext" %}} -만약 태스크 페이지를 작성하고 싶다면, -[문서 풀 리퀘스트(Pull Request) 생성하기](/docs/home/contribute/create-pull-request/)를 참조한다. - - +만약 태스크 페이지를 작성하고 싶다면, +[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다. diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md index 4cb552677c..603b186517 100755 --- a/content/ko/docs/tasks/access-application-cluster/_index.md +++ b/content/ko/docs/tasks/access-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 내 어플리케이션 액세스" +description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다. weight: 60 --- diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index ded8f15aad..c17458a912 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -145,7 +145,7 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure 위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 서버 접속에 사용한다. -(이들은 `~/.kube` 디렉토리에 설치된다.) +(이들은 `~/.kube` 디렉터리에 설치된다.) 일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 0218324ff2..5a585eddd4 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -139,7 +139,7 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 * [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다. -* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 +* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다. * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다. @@ -147,8 +147,3 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다. * [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 확인한다. - - - - - diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index e279148e33..9f99c6acbd 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -46,7 +46,7 @@ card: 네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. -`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 +`config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. ```shell @@ -76,7 +76,7 @@ contexts: 구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다. -`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 +`config-exercise` 디렉터리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 세부사항들을 추가한다. ```shell @@ -245,7 +245,7 @@ kubectl config --kubeconfig=config-demo view --minify ## 두 번째 구성 파일 생성 -`config-exercise` 디렉토리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다. +`config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다. ```shell apiVersion: v1 @@ -268,31 +268,31 @@ contexts: 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다. 예: -### Linux +### 리눅스 ```shell export KUBECONFIG_SAVED=$KUBECONFIG ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 -Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. +리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다. `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 익숙해지길 바란다. 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자. -### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG=("config-demo;config-demo-2") ``` -`config-exercise` 디렉토리에서 다음 커맨드를 입력한다. +`config-exercise` 디렉터리에서 다음 커맨드를 입력한다. ```shell kubectl config view @@ -330,14 +330,14 @@ contexts: kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다. -## $HOME/.kube 디렉토리 탐색 +## $HOME/.kube 디렉터리 탐색 만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 -해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 +해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉터리에 `config`라는 파일을 가지고 있을 것이다. `$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. -보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. +보통 `config`라는 파일이 존재할 것이다. 해당 디렉터리 내에는 다른 구성 파일들도 있을 수 있다. 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다. ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가 @@ -346,17 +346,17 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자. 예: -### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` -### Windows Powershell +### 윈도우 Powershell ```shell $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. -config-exercise 디렉토리에서 다음 커맨드를 실행한다. +config-exercise 디렉터리에서 다음 커맨드를 실행한다. ```shell kubectl config view @@ -366,12 +366,12 @@ kubectl config view `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:
-### Linux +### 리눅스 ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` -### Windows PowerShell +### 윈도우 PowerShell ```shell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 75bfb61a76..711130bbb4 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -119,15 +119,15 @@ track=stable - **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다. -- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. +- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. -- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. +- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. - **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. ### YAML 또는 JSON 파일 업로드 -쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. +쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. 배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. @@ -144,9 +144,9 @@ track=stable 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. #### 워크로드 -선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. -워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. +워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. #### 서비스 외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. @@ -169,5 +169,3 @@ track=stable 더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. - - diff --git a/content/ko/docs/tasks/administer-cluster/_index.md b/content/ko/docs/tasks/administer-cluster/_index.md index 77ca3f2479..4913ccf73e 100755 --- a/content/ko/docs/tasks/administer-cluster/_index.md +++ b/content/ko/docs/tasks/administer-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 운영" +description: 클러스터를 운영하기 위한 공통 태스크를 배운다. weight: 20 --- diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md new file mode 100644 index 0000000000..1b92c1283a --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -0,0 +1,451 @@ +--- +title: 쿠버네티스 API를 사용하여 클러스터에 접근하기 +content_type: task +--- + + +이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## 쿠버네티스 API에 접근 + +### kubectl을 사용하여 처음으로 접근 + +쿠버네티스 API에 처음 접근하는 경우, 쿠버네티스 +커맨드 라인 도구인 `kubectl` 을 사용한다. + +클러스터에 접근하려면, 클러스터 위치를 알고 접근할 수 있는 자격 증명이 +있어야 한다. 일반적으로, [시작하기 가이드](/ko/docs/setup/)를 +통해 작업하거나, +다른 사람이 클러스터를 설정하고 자격 증명과 위치를 제공할 때 자동으로 설정된다. + +다음의 명령으로 kubectl이 알고 있는 위치와 자격 증명을 확인한다. + +```shell +kubectl config view +``` + +많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를 +제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다. + +### REST API에 직접 접근 + +kubectl은 API 서버 찾기와 인증을 처리한다. `curl` 이나 `wget` 과 같은 http 클라이언트 또는 브라우저를 사용하여 REST API에 +직접 접근하려는 경우, API 서버를 찾고 인증할 수 있는 여러 가지 방법이 있다. + + 1. 프록시 모드에서 kubectl을 실행한다(권장). 이 방법은 저장된 API 서버 위치를 사용하고 자체 서명된 인증서를 사용하여 API 서버의 ID를 확인하므로 권장한다. 이 방법을 사용하면 중간자(man-in-the-middle, MITM) 공격이 불가능하다. + 1. 또는, 위치와 자격 증명을 http 클라이언트에 직접 제공할 수 있다. 이 방법은 프록시를 혼란스럽게 하는 클라이언트 코드와 동작한다. 중간자 공격으로부터 보호하려면, 브라우저로 루트 인증서를 가져와야 한다. + + Go 또는 Python 클라이언트 라이브러리를 사용하면 프록시 모드에서 kubectl에 접근할 수 있다. + +#### kubectl 프록시 사용 + +다음 명령은 kubectl을 리버스 프록시로 작동하는 모드에서 실행한다. API +서버 찾기와 인증을 처리한다. + +다음과 같이 실행한다. + +```shell +kubectl proxy --port=8080 & +``` + +자세한 내용은 [kubectl 프록시](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참고한다. + +그런 다음 curl, wget 또는 브라우저를 사용하여 API를 탐색할 수 있다. + +```shell +curl http://localhost:8080/api/ +``` + +출력은 다음과 비슷하다. + +```json +{ + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +#### kubectl 프록시 없이 접근 + +다음과 같이 인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 +사용을 피할 수 있다. + +`grep/cut` 방식을 사용한다. + +```shell +# .KUBECONFIG에 여러 콘텍스트가 있을 수 있으므로, 가능한 모든 클러스터를 확인한다. +kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}' + +# 위의 출력에서 상호 작용하려는 클러스터의 이름을 선택한다. +export CLUSTER_NAME="some_server_name" + +# 클러스터 이름을 참조하는 API 서버를 가리킨다. +APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}") + +# 토큰 값을 얻는다 +TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode) + +# TOKEN으로 API 탐색 +curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +출력은 다음과 비슷하다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +`jsonpath` 방식을 사용한다. + +```shell +APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') +TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode ) +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +위의 예는 `--insecure` 플래그를 사용한다. 이로 인해 MITM 공격이 +발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와 +클라이언트 인증서를 사용하여 서버에 접근한다. (`~/.kube` 디렉터리에 +설치된다.) 클러스터 인증서는 일반적으로 자체 서명되므로, +http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이 +필요할 수 있다. + +일부 클러스터에서, API 서버는 인증이 필요하지 않다. +로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은 +없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은 +클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 +고 가용성 지원과 충돌할 수 있다. + +### API에 프로그래밍 방식으로 접근 + +쿠버네티스는 공식적으로 [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client) 및 [Haskell](#haskell-client) 용 클라이언트 라이브러리를 지원한다. 쿠버네티스 팀이 아닌 작성자가 제공하고 유지 관리하는 다른 클라이언트 라이브러리가 있다. 다른 언어에서 API에 접근하고 인증하는 방법에 대해서는 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 참고한다. + +#### Go 클라이언트 {#go-client} + +* 라이브러리를 얻으려면, 다음 명령을 실행한다. `go get k8s.io/client-go@kubernetes-` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases)를 참고한다. +* client-go 클라이언트 위에 애플리케이션을 작성한다. + +{{< note >}} + +client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기본 리포지터리가 아닌 client-go에서 API 정의를 가져온다. 예를 들어, `import "k8s.io/client-go/kubernetes"` 가 맞다. + +{{< /note >}} + +Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. + +```golang +import ( + "fmt" + "k8s.io/apimachinery/pkg/apis/meta/v1" + "k8s.io/client-go/kubernetes" + "k8s.io/client-go/tools/clientcmd" +) + +func main() { + // kubeconfig에서 현재 콘텍스트를 사용한다 + // path-to-kubeconfig -- 예를 들어, /root/.kube/config + config, _ := clientcmd.BuildConfigFromFlags("", "") + // clientset을 생성한다 + clientset, _ := kubernetes.NewForConfig(config) + // 파드를 나열하기 위해 API에 접근한다 + pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{}) + fmt.Printf("There are %d pods in the cluster\n", len(pods.Items)) +} +``` + +애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다. + +#### Python 클라이언트 {#python-client} + +[Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다. + +Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다. + +```python +from kubernetes import client, config + +config.load_kube_config() + +v1=client.CoreV1Api() +print("Listing pods with their IPs:") +ret = v1.list_pod_for_all_namespaces(watch=False) +for i in ret.items: + print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name)) +``` + +#### Java 클라이언트 {#java-client} + +* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다. + +```shell +# java 라이브러리를 클론한다 +git clone --recursive https://github.com/kubernetes-client/java + +# 프로젝트 아티팩트, POM 등을 설치한다 +cd java +mvn install +``` + +어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다. + +Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다. + +```java +package io.kubernetes.client.examples; + +import io.kubernetes.client.ApiClient; +import io.kubernetes.client.ApiException; +import io.kubernetes.client.Configuration; +import io.kubernetes.client.apis.CoreV1Api; +import io.kubernetes.client.models.V1Pod; +import io.kubernetes.client.models.V1PodList; +import io.kubernetes.client.util.ClientBuilder; +import io.kubernetes.client.util.KubeConfig; +import java.io.FileReader; +import java.io.IOException; + +/** + * 쿠버네티스 클러스터 외부의 애플리케이션에서 Java API를 사용하는 방법에 대한 간단한 예 + * + *

이것을 실행하는 가장 쉬운 방법: mvn exec:java + * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample" + * + */ +public class KubeConfigFileClientExample { + public static void main(String[] args) throws IOException, ApiException { + + // KubeConfig의 파일 경로 + String kubeConfigPath = "~/.kube/config"; + + // 파일시스템에서 클러스터 외부 구성인 kubeconfig 로드 + ApiClient client = + ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build(); + + // 전역 디폴트 api-client를 위에서 정의한 클러스터 내 클라이언트로 설정 + Configuration.setDefaultApiClient(client); + + // CoreV1Api는 전역 구성에서 디폴트 api-client를 로드 + CoreV1Api api = new CoreV1Api(); + + // CoreV1Api 클라이언트를 호출한다 + V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null); + System.out.println("Listing all pods: "); + for (V1Pod item : list.getItems()) { + System.out.println(item.getMetadata().getName()); + } + } +} +``` + +#### dotnet 클라이언트 {#dotnet-client} + +[dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다. + +dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다. + +```csharp +using System; +using k8s; + +namespace simple +{ + internal class PodList + { + private static void Main(string[] args) + { + var config = KubernetesClientConfiguration.BuildDefaultConfig(); + IKubernetes client = new Kubernetes(config); + Console.WriteLine("Starting Request!"); + + var list = client.ListNamespacedPod("default"); + foreach (var item in list.Items) + { + Console.WriteLine(item.Metadata.Name); + } + if (list.Items.Count == 0) + { + Console.WriteLine("Empty!"); + } + } + } +} +``` + +#### JavaScript 클라이언트 {#javascript-client} + +[JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다. + +JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다. + +```javascript +const k8s = require('@kubernetes/client-node'); + +const kc = new k8s.KubeConfig(); +kc.loadFromDefault(); + +const k8sApi = kc.makeApiClient(k8s.CoreV1Api); + +k8sApi.listNamespacedPod('default').then((res) => { + console.log(res.body); +}); +``` + +#### Haskell 클라이언트 {#haskell-client} + +어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases)를 참고한다. + +Haskell 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs)를 참고한다. + +```haskell +exampleWithKubeConfig :: IO () +exampleWithKubeConfig = do + oidcCache <- atomically $ newTVar $ Map.fromList [] + (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig" + dispatchMime + mgr + kcfg + (CoreV1.listPodForAllNamespaces (Accept MimeJSON)) + >>= print +``` + + +### 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod} + +파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은 +위에서 설명한 외부 클라이언트 사례와 약간 다르다. + +파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은 +공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한 +라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다. + +#### 공식 클라이언트 라이브러리 사용 + +파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다. + + - Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다. + `rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다. + [여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다. + + - Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다. + `config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다. + [여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다. + + - 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다. + +각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와 +안전하게 통신하는 데 사용된다. + +#### REST API에 직접 접근 + +파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는 +서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc` +호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는 +이를 자동으로 수행한다. + +API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts) +자격 증명을 사용하는 것이다. 기본적으로, 파드는 +서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은 +해당 파드에 있는 각 컨테이너의 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다. + +사용 가능한 경우, 인증서 번들은 각 컨테이너의 +파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며, +API 서버의 제공 인증서를 확인하는 데 사용해야 한다. + +마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의 +`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다. + +#### kubectl 프록시 사용 + +공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서 +새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로 +`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는 +API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의 +다른 컨테이너가 직접 사용할 수 있도록 한다. + +#### 프록시를 사용하지 않고 접근 + +인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을 +피할 수 있다. 내부 인증서는 연결을 보호한다. + +```shell +# 내부 API 서버 호스트 이름을 가리킨다 +APISERVER=https://kubernetes.default.svc + +# ServiceAccount 토큰 경로 +SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount + +# 이 파드의 네임스페이스를 읽는다 +NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) + +# ServiceAccount 베어러 토큰을 읽는다 +TOKEN=$(cat ${SERVICEACCOUNT}/token) + +# 내부 인증 기관(CA)을 참조한다 +CACERT=${SERVICEACCOUNT}/ca.crt + +# TOKEN으로 API를 탐색한다 +curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api +``` + +출력은 다음과 비슷하다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md new file mode 100644 index 0000000000..0b1cf9540f --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -0,0 +1,134 @@ +--- +title: 클러스터에서 실행되는 서비스에 접근 +content_type: task +--- + + +이 페이지는 쿠버네티스 클러스터에서 실행되는 서비스에 연결하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## 클러스터에서 실행되는 서비스에 접근 + +쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 +고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수 +없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서 +도달할 수 없다. + +### 연결하는 방법 + +클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다. + + - 퍼블릭 IP를 통해 서비스에 접근한다. + - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서 + 접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와 + [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다. + - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다. + 자체 인증을 수행하는가? + - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, + 파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다. + - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접 + 접근할 필요는 없다. + - 프록시 작업(Proxy Verb)을 사용하여 서비스, 노드 또는 파드에 접근한다. + - 원격 서비스에 접근하기 전에 apiserver 인증과 권한 부여를 수행한다. + 서비스가 인터넷에 노출되거나, 노드 IP의 포트에 접근하거나, 디버깅하기에 + 충분히 안전하지 않은 경우 사용한다. + - 프록시는 일부 웹 애플리케이션에 문제를 일으킬 수 있다. + - HTTP/HTTPS에서만 작동한다. + - [여기](#apiserver-프록시-url-수동-구성)에 설명되어 있다. + - 클러스터의 노드 또는 파드에서 접근한다. + - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 셸에 연결한다. + 해당 셸에서 다른 노드, 파드 및 서비스에 연결한다. + - 일부 클러스터는 클러스터의 노드로 ssh를 통해 접근하는 것을 허용한다. 거기에서 클러스터 서비스에 + 접근할 수 있다. 이것은 비표준 방법이며, 일부 클러스터에서는 작동하지만 다른 클러스터에서는 + 작동하지 않는다. 브라우저 및 기타 도구가 설치되거나 설치되지 않을 수 있다. 클러스터 DNS가 작동하지 않을 수도 있다. + +### 빌트인 서비스 검색 + +일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을 +사용하여 이들의 목록을 얻는다. + +```shell +kubectl cluster-info +``` + +출력은 다음과 비슷하다. + +``` +Kubernetes master is running at https://104.197.5.247 +elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy +kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy +kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy +grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +``` + +각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다. +예를 들어, 이 클러스터에는 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로 +접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다. +`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. + +{{< note >}} +자격 증명을 전달하거나 kubectl proxy를 사용하는 방법은 [쿠버네티스 API를 사용하여 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)를 참고한다. +{{< /note >}} + +#### apiserver 프록시 URL 수동 구성 + +위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다. +`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` + +포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. + +##### 예제 + +* Elasticsearch 서비스 엔드포인트 `_search?q=user:kimchy` 에 접근하려면, 다음을 사용한다. + + ``` + http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy + ``` + +* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. + + ``` + https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true + ``` + + 상태 정보는 다음과 비슷하다. + + ```json + { + "cluster_name" : "kubernetes_logging", + "status" : "yellow", + "timed_out" : false, + "number_of_nodes" : 1, + "number_of_data_nodes" : 1, + "active_primary_shards" : 5, + "active_shards" : 5, + "relocating_shards" : 0, + "initializing_shards" : 0, + "unassigned_shards" : 5 + } + ``` + +* *https* Elasticsearch 서비스 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. + + ``` + https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true + ``` + +#### 웹 브라우저를 사용하여 클러스터에서 실행되는 서비스에 접근 + +브라우저의 주소 표시줄에 apiserver 프록시 URL을 넣을 수 있다. 그러나, + + - 웹 브라우저는 일반적으로 토큰을 전달할 수 없으므로, 기본 (비밀번호) 인증을 사용해야 할 수도 있다. Apiserver는 기본 인증을 수락하도록 구성할 수 있지만, + 클러스터는 기본 인증을 수락하도록 구성되지 않을 수 있다. + - 일부 웹 앱, 특히 프록시 경로 접두사를 인식하지 못하는 방식으로 URL을 구성하는 클라이언트 측 자바스크립트가 있는 + 웹 앱이 작동하지 않을 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md index 9c9341919a..8fd7445fb7 100644 --- a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -4,7 +4,7 @@ content_type: task --- -이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 +이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다. @@ -20,21 +20,21 @@ content_type: task ## 왜 기본 스토리지 클래스를 변경하는가? -설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 -스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 -스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 +설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 +스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 +스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 동적으로 프로비저닝 하기 위해 사용된다. -더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를 +더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)를 보자. -미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 -않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 -수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 +미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 +않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 +수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 하여 스토리지의 동적 프로비저닝을 방지할 수 있다. -단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 -애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 -및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. +단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 +애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 +및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. ## 기본 스토리지클래스 변경하기 @@ -56,7 +56,7 @@ content_type: task 1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다. - 기본 스토리지클래스에는 + 기본 스토리지클래스에는 `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다. 다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다. diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index b84b42b7e1..440ece1531 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -5,9 +5,9 @@ content_type: concept -이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, -클러스터의 마스터와 워커 노드들의 업그레이드, -노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 +이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, +클러스터의 마스터와 워커 노드들의 업그레이드, +노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 쿠버네티스 API 버전 업그레이드. @@ -25,17 +25,17 @@ content_type: concept ### Azure Kubernetes Service (AKS) 클러스터 업그레이드 -Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 +Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다. ### Google Compute Engine 클러스터 업그레이드 -Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 -재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 +Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 +재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 동일한 Persistent Disk(PD)를 유지한다. -GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 -순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 +GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 +순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다. open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다. @@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 ## 클러스터 크기 재조정 -[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. +[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다. ```shell @@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터 ### 클러스터 오토스케일링 -GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 +GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 재조정하도록 클러스터를 구성할 수 있다. -[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. -이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. -여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 +[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. +이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. +여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다. -Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 +Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다. -Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 +Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다. Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다. -GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. +GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다. * `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다. @@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설 KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh ``` -Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 -생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 +Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 +생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 전달하여 cluster autoscaler를 구성할 수 있다. 예제: @@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes= **Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.** -cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 -autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) +cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 +autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) 문서를 참조하기를 바란다. ## 노드 유지보수 -(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, -Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 -(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) -노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 -레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 +(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, +Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 +(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) +노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 +레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다. 만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다. @@ -167,9 +167,9 @@ kubectl drain $NODENAME 이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다. -레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다. +레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다. -레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다. +레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다. 해당 노드에 유지보수 작업을 수행한다. @@ -179,8 +179,8 @@ kubectl drain $NODENAME kubectl uncordon $NODENAME ``` -해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 -자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; +해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 +자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; 이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라. ## 고급 주제들 @@ -199,15 +199,15 @@ kubectl uncordon $NODENAME ### 클러스터에서 API 버전을 ON/OFF 하기 -특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 -전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. -예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. +특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 +전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. +예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. 이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`) ### 클러스터에서 스토리지 API 버전을 변경 클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다. -지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 +지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다. ### 구성 파일을 신규 API 버전으로 변경 @@ -219,5 +219,3 @@ kubectl convert -f pod.yaml --output-version v1 ``` 옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다. - - diff --git a/content/ko/docs/tasks/administer-cluster/extended-resource-node.md b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md new file mode 100644 index 0000000000..c9aed07263 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md @@ -0,0 +1,206 @@ +--- +title: 노드에 대한 확장 리소스 알리기 +content_type: task +--- + + + + +이 페이지는 노드의 확장 리소스를 지정하는 방법을 보여준다. +확장 리소스를 통해 클러스터 관리자는 쿠버네티스에게 +알려지지 않은 노드-레벨 리소스를 알릴 수 있다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## 노드의 이름을 확인한다 + +```shell +kubectl get nodes +``` + +이 연습에 사용할 노드 중 하나를 선택한다. + +## 노드 중 하나에 새로운 확장 리소스를 알린다 + +노드에서 새로운 확장 리소스를 알리려면, 쿠버네티스 API 서버에 +HTTP PATCH 요청을 보낸다. 예를 들어, 노드 중 하나에 4개의 동글(dongle)이 있다고 +가정한다. 다음은 노드에 4개의 동글 리소스를 알리는 PATCH 요청의 +예이다. + +```shell +PATCH /api/v1/nodes//status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/example.com~1dongle", + "value": "4" + } +] +``` + +참고로 쿠버네티스는 동글이 무엇인지 또는 동글이 무엇을 위한 것인지 알 필요가 없다. +위의 PATCH 요청은 노드에 동글이라고 하는 네 가지 항목이 있음을 +쿠버네티스에 알려준다. + +쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다. + +```shell +kubectl proxy +``` + +다른 명령 창에서 HTTP PATCH 요청을 보낸다. +`` 을 노드의 이름으로 바꾼다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \ +http://localhost:8001/api/v1/nodes//status +``` + +{{< note >}} +이전 요청에서 `~1` 은 패치 경로의 / 문자에 대한 +인코딩이다. JSON-Patch의 작업 경로값은 JSON-Pointer로 +해석된다. 자세한 내용은 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901)의 +섹션 3을 참고한다. +{{< /note >}} + +출력은 노드가 4개의 동글 용량을 가졌음을 나타낸다. + +``` +"capacity": { + "cpu": "2", + "memory": "2049008Ki", + "example.com/dongle": "4", +``` + +노드의 정보를 확인한다. + +``` +kubectl describe node +``` + +다시 한 번, 출력에 동글 리소스가 표시된다. + +```yaml +Capacity: + cpu: 2 + memory: 2049008Ki + example.com/dongle: 4 +``` + +이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를 +만들 수 있다. [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)를 +참고한다. + +## 토론 + +확장 리소스는 메모리 및 CPU 리소스와 비슷하다. 예를 들어, +노드에서 실행 중인 모든 컴포넌트가 공유할 특정 양의 메모리와 CPU가 +노드에 있는 것처럼, 노드에서 실행 중인 모든 컴포넌트가 +특정 동글을 공유할 수 있다. 또한 애플리케이션 개발자가 +특정 양의 메모리와 CPU를 요청하는 파드를 생성할 수 있는 것처럼, 특정 +동글을 요청하는 파드를 생성할 수 있다. + +확장 리소스는 쿠버네티스에게 불투명하다. 쿠버네티스는 그것들이 +무엇인지 전혀 모른다. 쿠버네티스는 노드에 특정 개수의 노드만 +있다는 것을 알고 있다. 확장 리소스는 정수로 알려야 +한다. 예를 들어, 노드는 4.5개의 동글이 아닌, 4개의 동글을 알릴 수 있다. + +### 스토리지 예제 + +노드에 800GiB의 특별한 종류의 디스크 스토리지가 있다고 가정한다. +example.com/special-storage와 같은 특별한 스토리지의 이름을 생성할 수 있다. +그런 다음 특정 크기, 100GiB의 청크로 알릴 수 있다. 이 경우, +노드에는 example.com/special-storage 유형의 8가지 리소스가 있다고 +알린다. + +```yaml +Capacity: + ... + example.com/special-storage: 8 +``` + +이 특별한 스토리지에 대한 임의 요청을 허용하려면, +1바이트 크기의 청크로 특별한 스토리지를 알릴 수 있다. 이 경우, example.com/special-storage 유형의 +800Gi 리소스를 알린다. + +```yaml +Capacity: + ... + example.com/special-storage: 800Gi +``` + +그런 다음 컨테이너는 최대 800Gi의 임의 바이트 수의 특별한 스토리지를 요청할 수 있다. + +## 정리 + +다음은 노드에서 동글 알림을 제거하는 PATCH 요청이다. + +``` +PATCH /api/v1/nodes//status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "remove", + "path": "/status/capacity/example.com~1dongle", + } +] +``` + +쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다. + +```shell +kubectl proxy +``` + +다른 명령 창에서 HTTP PATCH 요청을 보낸다. +``을 노드의 이름으로 바꾼다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \ +http://localhost:8001/api/v1/nodes//status +``` + +동글 알림이 제거되었는지 확인한다. + +``` +kubectl describe node | grep dongle +``` + +(출력이 보이지 않아야 함) + + + + +## {{% heading "whatsnext" %}} + + +### 애플리케이션 개발자를 위한 문서 + +* [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/) + +### 클러스터 관리자를 위한 문서 + +* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 0388e2542b..2cf5a8b6e5 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,5 +1,5 @@ --- -title: Windows 노드 추가 +title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial weight: 30 @@ -9,7 +9,7 @@ weight: 30 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다. +쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다. @@ -17,8 +17,8 @@ weight: 30 ## {{% heading "prerequisites" %}} {{< version-check >}} -* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면 -[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다. +* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면 +[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다. VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다. * 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다. @@ -29,15 +29,15 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo ## {{% heading "objectives" %}} -* 클러스터에 Windows 노드 등록 -* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성 +* 클러스터에 윈도우 노드 등록 +* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성 -## 시작하기: 클러스터에 Windows 노드 추가 +## 시작하기: 클러스터에 윈도우 노드 추가 ### 네트워킹 구성 @@ -75,7 +75,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo } ``` - {{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를 + {{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를 참고한다.{{< /note >}} {{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}} @@ -102,9 +102,9 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo kube-system kube-flannel-ds-54954 1/1 Running 0 1m ``` -1. Windows 플란넬 및 kube-proxy 데몬셋 추가 +1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가 - 이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한 + 이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한 kube-proxy 버전을 얻으려면, 이미지의 태그를 대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만, 사용자의 배포에 맞게 버전을 조정해야 한다. @@ -118,7 +118,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo {{< /note >}} {{< note >}} -Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다. +윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다. ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" @@ -134,14 +134,14 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow -### Windows 워커 노드 조인(joining) +### 윈도우 워커 노드 조인(joining) {{< note >}} `Containers` 기능을 설치하고 도커를 설치해야 한다. -[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다. +[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다. {{< /note >}} {{< note >}} -Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의 +윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의 높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다. {{< /note >}} @@ -160,7 +160,7 @@ Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의 #### 설치 확인 -이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다. +이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다. ```bash kubectl get nodes -o wide @@ -180,6 +180,6 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드 ## {{% heading "whatsnext" %}} -- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) +- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index b6b1c878c6..9e48ea900a 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -242,7 +242,7 @@ min-kubernetes-server-version: 1.18 - CNI 제공자 플러그인을 수동으로 업그레이드한다. CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. - [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서 + [애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 779e6fe86a..66adcb6a9d 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -1,5 +1,5 @@ --- -title: Windows 노드 업그레이드 +title: 윈도우 노드 업그레이드 min-kubernetes-server-version: 1.17 content_type: task weight: 40 @@ -9,7 +9,7 @@ weight: 40 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 노드를 업그레이드하는 방법을 설명한다. +이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) 윈도우 노드를 업그레이드하는 방법을 설명한다. @@ -18,7 +18,7 @@ weight: 40 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에 -익숙해져야 한다. Windows 노드를 +익숙해져야 한다. 윈도우 노드를 업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다. @@ -30,7 +30,7 @@ weight: 40 ### kubeadm 업그레이드 -1. Windows 노드에서, kubeadm을 업그레이드한다. +1. 윈도우 노드에서, kubeadm을 업그레이드한다. ```powershell # replace {{< param "fullversion" >}} with your desired version @@ -56,7 +56,7 @@ weight: 40 ### kubelet 구성 업그레이드 -1. Windows 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다. +1. 윈도우 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다. ```powershell kubeadm upgrade node @@ -64,7 +64,7 @@ weight: 40 ### kubelet 업그레이드 -1. Windows 노드에서, kubelet을 업그레이드하고 다시 시작한다. +1. 윈도우 노드에서, kubelet을 업그레이드하고 다시 시작한다. ```powershell stop-service kubelet diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 494a09418c..43160db786 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -265,7 +265,4 @@ kubectl delete namespace constraints-cpu-example * [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 769f0bfb09..ab77c226b0 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -188,6 +188,4 @@ kubectl delete namespace default-cpu-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index cf3cd826f6..19163fd7e7 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -265,6 +265,4 @@ kubectl delete namespace constraints-mem-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index 7127a7f235..a74d492e5a 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -196,8 +196,4 @@ kubectl delete namespace default-mem-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index ce16eaeef1..f17a387a5b 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -172,6 +172,4 @@ kubectl delete namespace quota-mem-cpu-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index 880444cefd..9c4d787429 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -133,11 +133,4 @@ kubectl delete namespace quota-pod-example * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) - - - - - - - +* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 5435bcf67a..fed25bc169 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -48,7 +48,7 @@ Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함 간단한 ``올인원`` YAML 파일로 배포할 수 있다. ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` ``` configmap/cilium-config created diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 462e482bff..70f0ec1aae 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -39,7 +39,3 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman 로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - - - - diff --git a/content/ko/docs/tasks/configure-pod-container/_index.md b/content/ko/docs/tasks/configure-pod-container/_index.md index 560261ecad..e43910867f 100644 --- a/content/ko/docs/tasks/configure-pod-container/_index.md +++ b/content/ko/docs/tasks/configure-pod-container/_index.md @@ -1,4 +1,5 @@ --- title: "파드와 컨테이너 설정" +description: 파드와 컨테이너에 대한 공통 구성 태스크들을 수행한다. weight: 20 --- diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 7083bdea67..980d71d9b5 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -25,7 +25,7 @@ weight: 10 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. -Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 +Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화할 수 있다. ```shell @@ -53,7 +53,7 @@ v1beta1.metrics.k8s.io ## 네임스페이스 생성 -이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 +이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다. ```shell @@ -113,7 +113,7 @@ kubectl top pod memory-demo --namespace=mem-example ``` 출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. -이는 파드의 100 MiB 요청 보다 많으나 +이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다. ``` @@ -245,7 +245,7 @@ kubectl delete pod memory-demo-2 --namespace=mem-example 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 -컨테이너를 갖는 +컨테이너를 갖는 파드의 구성 파일이다. {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -340,25 +340,20 @@ kubectl delete namespace mem-example * [CPU 리소스를 컨테이너와 파드에 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) -* [파드에 서비스 품질 설정](/docs/tasks/configure-pod-container/quality-service-pod/) +* [파드에 서비스 품질 설정](/ko/docs/tasks/configure-pod-container/quality-service-pod/) ### 클러스터 관리자들을 위한 -* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/docs/tasks/administer-cluster/memory-default-namespace/) +* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/docs/tasks/administer-cluster/cpu-default-namespace/) - -* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/docs/tasks/administer-cluster/memory-constraint-namespace/) - -* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/docs/tasks/administer-cluster/cpu-constraint-namespace/) - -* [네임스페이스에 메모리 및 CPU 할당량 구성](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) - -* [네임스페이스에 파드 할당량 구성](/docs/tasks/administer-cluster/quota-pod-namespace/) - -* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/) +* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) +* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) +* [네임스페이스에 메모리 및 CPU 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) +* [네임스페이스에 파드 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) +* [API 오브젝트에 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md index bc1446946d..5ad8b72d52 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -117,6 +117,5 @@ weight: 120 ## {{% heading "whatsnext" %}} -[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)에 +[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)에 대해 더 알아보기. - diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md index cff2ae900d..d973b42f99 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -89,7 +89,3 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다. * [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기. * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기. * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. - - - - diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index a6ddeae8fb..8eb1c0a68f 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -9,10 +9,10 @@ content_template: task -*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} -없이 특정 노드에 있는 kubelet 데몬에 의해 +*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +없이 특정 노드에 있는 kubelet 데몬에 의해 직접 관리된다. -컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, +컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, kubelet 이 각각의 스태틱 파드를 감시한다. (만약 충돌이 날 경우 다시 구동한다.) @@ -20,13 +20,13 @@ kubelet 이 각각의 스태틱 파드를 감시한다. Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를 생성하려고 자동으로 시도한다. -즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, +즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, API 서버에서 제어될 수는 없다. {{< note >}} -만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 +만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 모든 노드에서 파드를 구동하고 있다면, -스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} +스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} 을 사용하는 것이 바람직하다. {{< /note >}} @@ -37,7 +37,7 @@ API 서버에서 제어될 수는 없다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, +이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. @@ -49,12 +49,12 @@ API 서버에서 제어될 수는 없다. ## 스태틱 파드 생성하기 {#static-pod-creation} -[파일 시스템이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다. +[파일 시스템이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다. ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} -매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. -Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. +매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. @@ -64,7 +64,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단 ssh my-node1 ``` -2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다. +2. `/etc/kubelet.d` 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다. ```shell # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. @@ -87,7 +87,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단 EOF ``` -3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. +3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. ``` KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" @@ -103,10 +103,10 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단 ### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} -Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으로 다운로드하여 +Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으로 다운로드하여 해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다. -[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 -유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 +[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 +유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 변경된 부분이 있을 경우, kubelet 은 이를 적용한다. 이 방법을 사용하기 위하여 다음을 수행한다. @@ -130,7 +130,7 @@ Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으 protocol: TCP ``` -2. 선택한 노드에서 `--manifest-url=` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. +2. 선택한 노드에서 `--manifest-url=` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. ``` KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" @@ -145,7 +145,7 @@ Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으 ## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods} -Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. +Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. 스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱 파드가 이미 실행 중이어야 한다. @@ -174,15 +174,15 @@ static-web-my-node1 1/1 Running 0 2m {{< note >}} Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. -[파드시큐리티폴리시(PodSecurityPolicy)](/docs/concepts/policy/pod-security-policy/) 에 대해 보기. +[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기. {{< /note >}} -스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 -미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 +스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 +미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 통하여 이러한 레이블을 사용할 수 있다. -만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, +만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, kubelet 은 스태틱 파드를 지우지 _않는다._ ```shell @@ -200,9 +200,9 @@ NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s ``` -kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 +kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 중지할 수 있다. -일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 +일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 것을 볼 수 있다. ```shell @@ -218,7 +218,7 @@ CONTAINER ID IMAGE COMMAND CREATED ... ## 스태틱 파드의 동적 추가 및 제거 -실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다. +실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다. ```shell # 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다. @@ -227,7 +227,7 @@ CONTAINER ID IMAGE COMMAND CREATED ... mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 docker ps -# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. +# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 docker ps diff --git a/content/ko/docs/tasks/debug-application-cluster/_index.md b/content/ko/docs/tasks/debug-application-cluster/_index.md index 0613fed1ef..d0bda0ea0f 100755 --- a/content/ko/docs/tasks/debug-application-cluster/_index.md +++ b/content/ko/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "모니터링, 로깅, 그리고 디버깅" +description: 모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다. weight: 80 --- diff --git a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 246e6af3bb..407c351050 100644 --- a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -5,15 +5,15 @@ content_template: templates/task -이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 +이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 방법을 보여준다. -종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, +종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, 대시보드나 모니터링 소프트웨어 도구와 같이 -쉽게 조회 및 표시할 수 있는 위치에 +쉽게 조회 및 표시할 수 있는 위치에 기록하는 방법을 제공한다. -대부분의 경우에 종료 메시지에 넣는 정보는 -일반 +대부분의 경우에 종료 메시지에 넣는 정보는 +일반 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다. @@ -32,7 +32,7 @@ content_template: templates/task ## 종료 메시지 읽기 및 쓰기 이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다. -하단의 설정 파일은 컨테이너가 시작될 때 수행하는 +하단의 설정 파일은 컨테이너가 시작될 때 수행하는 명령어를 지정한다. {{< codenew file="debug/termination.yaml" >}} @@ -41,8 +41,8 @@ content_template: templates/task kubectl apply -f https://k8s.io/examples/debug/termination.yaml - YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 - "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 + YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 + "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를 기록한 후에 종료된다. @@ -70,25 +70,25 @@ content_template: templates/task Sleep expired ... -1. 종료 메시지만을 포함하는 출력 결과를 보기 +1. 종료 메시지만을 포함하는 출력 결과를 보기 위해서는 Go 템플릿을 사용한다. kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" ## 종료 메시지 사용자 정의하기 -쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된 -종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은 -`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써 -쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. +쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된 +종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은 +`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써 +쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다. 종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다. -kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 -12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. +kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 +12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. 파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다. -다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 +다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 `/tmp/my-log` 파일에 종료 메시지를 기록한다. ```yaml @@ -103,12 +103,12 @@ spec: terminationMessagePath: "/tmp/my-log" ``` -또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy` -필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며, -이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다. -`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로 -설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우 -쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. +또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy` +필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며, +이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다. +`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로 +설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우 +쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다. @@ -118,9 +118,5 @@ spec: * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 에 있는 `terminationMessagePath` 에 대해 읽어보기. -* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기. +* [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기. * [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기. - - - - diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index d52a6127be..ee6991ef30 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -5,10 +5,10 @@ content_type: concept -컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 -쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 -`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, -Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. +컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 +쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 +`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, +Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. @@ -17,9 +17,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ## 메트릭 API -메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 -리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 -않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 +메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 +리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 +않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 가져오는 것과 같은 일을 할 수는 없다. 이 API와 다른 API는 차이가 없다. @@ -27,7 +27,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 - 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다 - 동일한 보안, 확장성 및 신뢰성 보장을 제공한다 -[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) +[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) 리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다. {{< note >}} @@ -38,7 +38,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ### CPU -CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다. +CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다. ### 메모리 @@ -47,15 +47,13 @@ CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/con ## 메트릭 서버 [메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 -디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 +`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 +디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다. 메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. -메트릭 서버는 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 +메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 통해 메인 API 서버에 등록된다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. - - diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index 1a72dbf241..d3b06d2703 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -1,6 +1,6 @@ --- title: 플러그인으로 kubectl 확장 -description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다. +description: kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다. content_type: task --- diff --git a/content/ko/docs/tasks/inject-data-application/_index.md b/content/ko/docs/tasks/inject-data-application/_index.md index e7ae5375f4..c5bddeca7e 100644 --- a/content/ko/docs/tasks/inject-data-application/_index.md +++ b/content/ko/docs/tasks/inject-data-application/_index.md @@ -1,5 +1,5 @@ --- title: "애플리케이션에 데이터 주입하기" +description: 워크로드를 실행하는 파드에 대한 구성과 기타 데이터를 지정한다. weight: 30 - ---- \ No newline at end of file +--- diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md index 8f821c7cf5..68ee4726a5 100644 --- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -30,9 +30,9 @@ weight: 10 파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고 난 이후에는 변경될 수 없다. -구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 -제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 -정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 +구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 +제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 +정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 함께 사용된다. {{< note >}} @@ -103,7 +103,7 @@ args: ["$(MESSAGE)"] ## 셸 안에서 커맨드 실행하기 일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가 -서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 +서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다. ```shell @@ -122,18 +122,18 @@ args: ["-c", "while true; do echo hello; sleep 10;done"] 기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다. -* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 +* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 제공되는 기본 값들이 사용된다. -* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, -제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 +* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, +제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 Cmd 값은 덮어쓰여진다. -* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint +* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint 값이 정의한 `args` 값들과 함께 실행된다. -* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 -EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 +* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 +EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 실행된다. 여기 몇 가지 예시들이 있다. @@ -154,7 +154,3 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값 * [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다. * [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다. * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다. - - - - diff --git a/content/ko/docs/tasks/manage-daemon/_index.md b/content/ko/docs/tasks/manage-daemon/_index.md index 58b87271c9..1ff595ef61 100644 --- a/content/ko/docs/tasks/manage-daemon/_index.md +++ b/content/ko/docs/tasks/manage-daemon/_index.md @@ -1,4 +1,5 @@ --- title: "클러스터 데몬 관리" +description: 롤링 업데이트 수행과 같은 데몬셋 관리를 위한 일반적인 작업을 수행한다. weight: 130 --- diff --git a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md index 60aa4f4d1a..0c79ae8d66 100644 --- a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -2,27 +2,20 @@ title: 데몬셋(DaemonSet)에서 롤백 수행 content_type: task weight: 20 +min-kubernetes-server-version: 1.7 --- - - -이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다. - - +이 페이지는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}에서 롤백을 수행하는 방법을 보여준다. ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은 - 쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다. -* [데몬셋에서 롤링 업데이트를 - 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다. - - - +[데몬셋에서 롤링 업데이트를 + 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 이미 알고 있어야 한다. @@ -40,7 +33,7 @@ kubectl rollout history daemonset 이 명령은 데몬셋 리비전 목록을 반환한다. -```shell +``` daemonsets "" REVISION CHANGE-CAUSE 1 ... @@ -60,17 +53,17 @@ kubectl rollout history daemonset --revision=1 이 명령은 해당 리비전의 세부 사항을 반환한다. -```shell +``` daemonsets "" with revision #1 Pod Template: Labels: foo=bar Containers: app: - Image: ... - Port: ... - Environment: ... - Mounts: ... -Volumes: ... + Image: ... + Port: ... + Environment: ... + Mounts: ... +Volumes: ... ``` ### 2단계: 특정 리비전으로 롤백 @@ -82,16 +75,19 @@ kubectl rollout undo daemonset --to-revision= 성공하면, 명령은 다음을 반환한다. -```shell +``` daemonset "" rolled back ``` -`--to-revision` 플래그를 지정하지 않은 경우, 마지막 리비전이 선택된다. +{{< note >}} +`--to-revision` 플래그를 지정하지 않은 경우, kubectl은 가장 최신의 리비전을 선택한다. +{{< /note >}} ### 3단계: 데몬셋 롤백 진행 상황 확인 `kubectl rollout undo daemonset` 은 서버에 데몬셋 롤백을 시작하도록 -지시한다. 실제 롤백은 서버 측에서 비동기적으로 수행된다. +지시한다. 실제 롤백은 클러스터 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}} +내에서 비동기적으로 수행된다. 롤백 진행 상황을 보려면 다음의 명령을 수행한다. @@ -101,21 +97,17 @@ kubectl rollout status ds/ 롤백이 완료되면, 출력 결과는 다음과 비슷하다. -```shell +``` daemonset "" successfully rolled out ``` - - ## 데몬셋 리비전의 이해 이전 `kubectl rollout history` 단계에서, 데몬셋 리비전 목록을 -얻었다. 각 리비전은 `ControllerRevision` 이라는 리소스에 저장된다. -`ControllerRevision` 은 쿠버네티스 릴리스 1.7 이상에서만 사용할 수 있는 -리소스이다. +얻었다. 각 리비전은 ControllerRevision이라는 리소스에 저장된다. 각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를 찾는다. @@ -124,30 +116,29 @@ daemonset "" successfully rolled out kubectl get controllerrevision -l = ``` -이 명령은 `ControllerRevisions` 의 목록을 반환한다. +이 명령은 ControllerRevision의 목록을 반환한다. -```shell +``` NAME CONTROLLER REVISION AGE - DaemonSet/ 1 1h - DaemonSet/ 2 1h ``` -각 `ControllerRevision` 은 데몬셋 리비전의 어노테이션과 템플릿을 -저장한다. ControllerRevision 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +각 ControllerRevision은 데몬셋 리비전의 어노테이션과 템플릿을 +저장한다. -`kubectl rollout undo` 는 특정 `ControllerRevision` 을 가져와 데몬셋 -템플릿을 `ControllerRevision` 에 저장된 템플릿으로 바꾼다. +`kubectl rollout undo` 는 특정 ControllerRevision을 가져와 데몬셋 +템플릿을 ControllerRevision에 저장된 템플릿으로 바꾼다. `kubectl rollout undo` 는 `kubectl edit` 또는 `kubectl apply` 와 같은 다른 명령을 통해 데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과 같다. {{< note >}} 데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이 -완료된 후, 롤백될 `ControllerRevision` 의 +완료된 후, 롤백될 ControllerRevision의 리비전 번호(`.revision` 필드)가 증가한다. 예를 들어, 시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면, -`ControllerRevision` 은 `.revision: 1` 에서 `.revision: 3` 이 된다. +ControllerRevision은 `.revision: 1` 에서 `.revision: 3` 이 된다. {{< /note >}} ## 문제 해결 @@ -157,4 +148,3 @@ NAME CONTROLLER REVISION AGE - diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 7ea6b51d93..78c5dc2cbd 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,6 +1,7 @@ --- content_type: concept title: GPU 스케줄링 +description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다. --- @@ -140,7 +141,7 @@ Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud 만약 클러스터의 노드들이 서로 다른 타입의 GPU를 가지고 있다면, 사용자는 파드를 적합한 노드에 스케줄 하기 위해서 -[노드 레이블과 노드 셀렉터](/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다. +[노드 레이블과 노드 셀렉터](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다. 예를 들면, @@ -215,5 +216,3 @@ spec: 이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록 만든다. - - diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index 9d4e4ca2b3..edb0edb08f 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -1,16 +1,14 @@ --- title: HugePages 관리 content_type: task +description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다. --- {{< feature-state state="stable" >}} -쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된 -huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 -huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다. - - +쿠버네티스는 파드의 애플리케이션에 미리 할당된 +huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법에 대해 설명한다. ## {{% heading "prerequisites" %}} @@ -118,11 +116,3 @@ glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. - -## 향후 버전 - -- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다. -- 리밋레인지(LimitRange)를 지원할 예정이다. - - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md index 3c6566741c..ebb3c90272 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md @@ -1,4 +1,5 @@ --- title: "쿠버네티스 오브젝트 관리" +description: 쿠버네티스 API와 상호 작용하기 위한 선언적이고 명령적인 패러다임 weight: 25 --- diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 87469281c9..f3b15d3206 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -16,7 +16,7 @@ weight: 10 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)를 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -1007,5 +1007,3 @@ template: * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index ddf2c2f1b9..ac7690a325 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -12,7 +12,7 @@ weight: 30 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -169,5 +169,3 @@ kubectl create --edit -f /tmp/srv.yaml * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index 927c6df079..49691c341b 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -13,7 +13,7 @@ weight: 40 ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -152,5 +152,3 @@ template: * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 20435a4881..6a45b5a73b 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -6,12 +6,12 @@ weight: 20 -[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 -[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 +[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 +[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다. -1.14 이후로, kubectl도 -kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. +1.14 이후로, kubectl도 +kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. kustomization 파일을 포함하는 디렉터리 내의 리소스를 보려면 다음 명령어를 실행한다. ```shell @@ -29,7 +29,7 @@ kubectl apply -k ## {{% heading "prerequisites" %}} -[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -47,7 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다. ### 리소스 생성 -컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. +컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다. Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다. @@ -207,7 +207,7 @@ metadata: ### 교차 편집 필드 설정 -프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. +프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. 교차 편집 필드를 설정하는 몇 가지 사용 사례는 다음과 같다. * 모든 리소스에 동일한 네임스페이스를 설정 @@ -283,13 +283,13 @@ spec: ### 리소스 구성과 사용자 정의 -프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 -관리하는 것은 일반적이다. +프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 +관리하는 것은 일반적이다. Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다. #### 구성 -Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. +Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. 다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다. ```shell @@ -344,7 +344,7 @@ EOF #### 사용자 정의 -패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는 +패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는 `patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다. ```shell @@ -432,10 +432,10 @@ spec: - containerPort: 80 ``` -모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, -Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. -Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 -`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 +모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, +Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. +Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 +`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다. ```shell @@ -508,7 +508,7 @@ spec: - containerPort: 80 ``` -패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 +패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 기능도 제공한다. 예를 들어 `kustomization.yaml`의 `images` 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다. ```shell @@ -566,9 +566,9 @@ spec: - containerPort: 80 ``` -가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, -디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. -`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. +가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, +디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. +`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. 커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다. ```shell @@ -655,11 +655,11 @@ spec: ## Base와 Overlay -Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 -사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 -될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 -다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. -한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, +Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 +사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 +될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 +다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. +한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, 이들의 위에 사용자 정의도 가질 수 있다. 다음은 base에 대한 예이다. @@ -711,7 +711,7 @@ resources: EOF ``` -이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 +이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 서로 다른 overlay에 추가할 수 있다. 다음 예제는 동일한 base를 사용하는 두 overlay들이다. ```shell @@ -732,7 +732,7 @@ EOF ## Kustomize를 이용하여 오브젝트를 적용/확인/삭제하는 방법 -`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. +`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. `-k`는 다음과 같이 kustomization 디렉터리를 가리키고 있어야 한다는 것을 주의한다. ```shell @@ -835,5 +835,3 @@ deployment.apps "dev-my-nginx" deleted * [Kubectl Book](https://kubectl.docs.kubernetes.io) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/tasks/network/_index.md b/content/ko/docs/tasks/network/_index.md index 26317241ec..e7ab0fae52 100644 --- a/content/ko/docs/tasks/network/_index.md +++ b/content/ko/docs/tasks/network/_index.md @@ -1,4 +1,5 @@ --- -title: "네트워크" +title: "네트워킹" +description: 클러스터에 대한 네트워킹 설정 방법에 대해 배운다. weight: 160 --- diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 0bbb20b99d..5364e7bebb 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -12,7 +12,7 @@ content_type: task * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.) -* 이중 스택을 지원하는 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico) +* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico) * IPVS 모드로 구동되는 Kube-proxy * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터 @@ -155,5 +155,3 @@ my-service ClusterIP fe80:20d::d06b 80/TCP 9s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s ``` - - diff --git a/content/ko/docs/tasks/run-application/_index.md b/content/ko/docs/tasks/run-application/_index.md index 203d2eb39c..13039181be 100644 --- a/content/ko/docs/tasks/run-application/_index.md +++ b/content/ko/docs/tasks/run-application/_index.md @@ -1,4 +1,5 @@ --- title: "애플리케이션 실행" +description: 스테이트리스와 스테이트풀 애플리케이션 모두를 실행하고 관리한다. weight: 40 --- diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index ce5f030622..4c50079dc3 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -52,7 +52,7 @@ kubectl delete pods -l app=myapp ### 퍼시스턴트볼륨(PersistentVolume) -스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#termination-of-pods)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. +스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. {{< note >}} PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. @@ -82,7 +82,3 @@ kubectl delete pvc -l app=myapp [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. - - - - diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 6b294b7850..ee5db9d3f2 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -8,7 +8,7 @@ weight: 100 Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. +레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 2362c7f475..4afcb6927d 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -179,9 +179,9 @@ CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은 새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다. HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. API 오브젝트에 대한 자세한 내용은 -[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다. +[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다. ## kubectl에서 Horizontal Pod Autoscaler 지원 @@ -199,9 +199,9 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl` ## 롤링 업데이트 중 오토스케일링 -현재 쿠버네티스에서는 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다. +현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다. Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고, -디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다. +디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다. Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다. 즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`) @@ -229,7 +229,7 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야 한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가 워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을 -너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수 +너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수 있다. {{< /note >}} @@ -439,5 +439,3 @@ behavior: * 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. - - diff --git a/content/ko/docs/tasks/tls/_index.md b/content/ko/docs/tasks/tls/_index.md index 8607aa28d2..291b4b3eb1 100644 --- a/content/ko/docs/tasks/tls/_index.md +++ b/content/ko/docs/tasks/tls/_index.md @@ -1,5 +1,6 @@ --- title: "TLS" +description: TLS(Transport Layer Security)를 사용하여 클러스터 내 트래픽을 보호하는 방법을 이해한다. weight: 100 --- diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 799bc028f6..bcfcd12e4e 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -1,5 +1,6 @@ --- title: "도구 설치" +description: 컴퓨터에서 쿠버네티스 도구를 설정한다. weight: 10 --- diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index 4b498f27ef..e4c8011614 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -111,34 +111,34 @@ kubectl version --client 1. 최신 릴리스를 다운로드한다. - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ```bash + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` + + 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. + + 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` - 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. + kubectl 바이너리를 실행 가능하게 만든다. - 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` - -2. kubectl 바이너리를 실행 가능하게 만든다. - - ``` - chmod +x ./kubectl - ``` + ```bash + chmod +x ./kubectl + ``` 3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다. - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Homebrew를 사용하여 설치 @@ -146,21 +146,21 @@ macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경 1. 설치 명령을 실행한다. - ``` - brew install kubectl - ``` + ```bash + brew install kubectl + ``` - 또는 + 또는 - ``` - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Macports를 사용하여 설치 @@ -168,117 +168,123 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 1. 설치 명령을 실행한다. - ``` - sudo port selfupdate - sudo port install kubectl - ``` + ```bash + sudo port selfupdate + sudo port install kubectl + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` -## Windows에 kubectl 설치 +## 윈도우에 kubectl 설치 -### Windows에서 curl을 사용하여 kubectl 바이너리 설치 +### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다. - 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. + 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. + 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. 2. 바이너리를 PATH가 설정된 디렉터리에 추가한다. 3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} -[Windows용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다. +[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다. 도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 PATH 항목 앞에 PATH 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다. {{< /note >}} ### PSGallery에서 Powershell로 설치 -Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다. +윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다. 1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다). - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` + ```powershell + Install-Script -Name install-kubectl -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] + ``` -{{< note >}}`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.{{< /note >}} + {{< note >}} + `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다. + {{< /note >}} 설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다. 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` {{< note >}} 설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다. {{< /note >}} -### Chocolatey 또는 Scoop을 사용하여 Windows에 설치 +### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 -1. Windows에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. - -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} +1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + ``` + {{% /tab %}} + {{< /tabs >}} 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` -3. 홈 디렉토리로 이동한다. +3. 홈 디렉터리로 이동한다. + + ```powershell + # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE% + cd ~ + ``` - ``` - cd %USERPROFILE% - ``` 4. `.kube` 디렉터리를 생성한다. - ``` - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. 금방 생성한 `.kube` 디렉터리로 이동한다. - ``` - cd .kube - ``` + ```powershell + cd .kube + ``` 6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다. - ``` - New-Item config -type file - ``` + ```powershell + New-Item config -type file + ``` -{{< note >}}메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.{{< /note >}} +{{< note >}} +메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다. +{{< /note >}} ## Google Cloud SDK의 일부로 다운로드 @@ -288,15 +294,15 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다. 2. `kubectl` 설치 명령을 실행한다. - ``` - gcloud components install kubectl - ``` + ```shell + gcloud components install kubectl + ``` 3. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```shell + kubectl version --client + ``` ## kubectl 구성 확인 @@ -312,7 +318,7 @@ URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르 다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다. -```shell +``` The connection to the server was refused - did you specify the right host or port? ``` @@ -350,7 +356,7 @@ bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](ht 확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다. -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -362,17 +368,17 @@ source /usr/share/bash-completion/bash_completion - `~/.bashrc` 파일에서 완성 스크립트를 소싱한다. - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```bash echo 'alias k=kubectl' >>~/.bashrc echo 'complete -F __start_kubectl k' >>~/.bashrc ``` @@ -403,19 +409,19 @@ bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS 여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다. -```shell +```bash echo $BASH_VERSION ``` 너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다. -```shell +```bash brew install bash ``` 셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다. -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -429,13 +435,13 @@ Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다. bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다. -```shell +```bash brew install bash-completion@2 ``` 이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다. -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -448,29 +454,29 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" - 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다. - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다. - ```shell + ```bash echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다. - {{< note >}} - bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. - {{< /note >}} + {{< note >}} + bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. + {{< /note >}} 어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다. {{% /tab %}} @@ -481,13 +487,13 @@ Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생 모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다. -```shell +```zsh source <(kubectl completion zsh) ``` kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` @@ -496,16 +502,13 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc `complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다. -```shell +```zsh autoload -Uz compinit compinit ``` {{% /tab %}} {{< /tabs >}} - - - ## {{% heading "whatsnext" %}} * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) @@ -513,4 +516,3 @@ compinit * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다. * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기 - diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index dc43810c14..04c4ca64a6 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -65,7 +65,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for ### kubectl 설치 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#리눅스에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ## 하이퍼바이저(hypervisor) 설치 @@ -76,7 +76,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다. -이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. +이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. 데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다. @@ -119,7 +119,7 @@ sudo install minikube /usr/local/bin/ ### Homebrew를 이용해서 Minikube 설치하기 -또 다른 대안으로 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다. +또 다른 대안으로 리눅스 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다. ```shell brew install minikube @@ -129,7 +129,7 @@ brew install minikube {{% tab name="맥OS" %}} ### kubectl 설치 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#macos에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ### 하이퍼바이저(hypervisor) 설치 @@ -162,10 +162,10 @@ sudo mv minikube /usr/local/bin ``` {{% /tab %}} -{{% tab name="Windows" %}} +{{% tab name="윈도우" %}} ### kubectl 설치하기 -kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)의 요령을 따라서 설치할 수 있다. +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#windows에-kubectl-설치)의 요령을 따라서 설치할 수 있다. ### 하이퍼바이저(hypervisor) 설치하기 @@ -206,7 +206,7 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{< note >}} -`minikube start` 시 `--driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다. +`minikube start` 시 `--driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 지정하기 문서](/ko/docs/setup/learning-environment/minikube/#vm-드라이버-지정하기)에서 확인할 수 있다. {{< /note >}} diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 4a18224f02..493d31e95f 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -70,7 +70,7 @@ content_type: concept 튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 -[내용 페이지 유형](/docs/contribute/style/page-content-types/) +[콘텐츠 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index 7c14a811a5..bb28639e83 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -15,7 +15,7 @@ content_type: tutorial * 다음을 포함하는 `kustomization.yaml` 파일을 생성한다. * 컨피그 맵 생성자 * 컨피그 맵을 사용하는 파드 리소스 -* `kubectl apply -k ./`를 실행하여 작업한 디렉토리를 적용한다. +* `kubectl apply -k ./`를 실행하여 작업한 디렉터리를 적용한다. * 구성이 잘 적용되었는지 확인한다. @@ -65,7 +65,7 @@ resources: EOF ``` -컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉토리를 적용한다. +컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다. ```shell kubectl apply -k . diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 4549694159..9d71638252 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -118,7 +118,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ``` {{< note >}} - `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/docs/user-guide/kubectl-overview/)을 살펴보자. + `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자. {{< /note >}} ## 서비스 만들기 diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index aed0258cf6..6726fdd6e0 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10

쿠버네티스 서비스들에 대한 개요

-

쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리카 셋은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

+

쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리카셋(ReplicaSet)은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정된다 (여러분이 왜 스펙에 selector가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).

@@ -80,7 +80,7 @@ weight: 10
  • 태그들을 이용하는 객체들에 대한 분류
    • - +

    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 24405ac955..9790c1f31e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -44,7 +44,7 @@ weight: 10
    -

    kubectl run 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 +

    kubectl create deployment 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 디플로이먼트를 만들 수도 있다

    diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 4917fa5042..5c4d94f624 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -447,6 +447,6 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} * [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다. -* 어떻게 [외부 로드밸런서 생성](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. +* 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index d384d07655..03cfdf88c6 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,9 +6,9 @@ weight: 10 --- -이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드를 생성하고 삭제하며 -스케일링하고 업데이트하는지 시연한다. +이 튜토리얼은 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}}을 이용하여 +애플리케이션을 관리하는 방법을 소개한다. +어떻게 스테이트풀셋의 파드를 생성하고, 삭제하며, 스케일링하고, 업데이트하는지 시연한다. ## {{% heading "prerequisites" %}} @@ -22,13 +22,14 @@ weight: 10 * [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [kubectl CLI](/docs/user-guide/kubectl/) +* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구 +{{< note >}} 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, 튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 프로비저닝해야 한다. - +{{< /note >}} ## {{% heading "objectives" %}} @@ -46,7 +47,6 @@ weight: 10 * 스테이트풀셋은 어떻게 스케일링하는지 * 스테이트풀셋의 파드는 어떻게 업데이트하는지 - ## 스테이트풀셋 생성하기 @@ -74,20 +74,24 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` 상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 -실행하는 2개의 파드를 생성한다. `nginx` 서비스와 -`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자. +실행하는 2개의 파드를 생성한다. `nginx` 서비스의 정보를 가져온다. ```shell kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None 80/TCP 12s - +``` +그리고 `web` 스테이트풀셋 정보를 가져와서 모두 성공적으로 생성되었는지 확인한다. +```shell kubectl get statefulset web +``` NAME DESIRED CURRENT AGE web 2 1 20s ``` @@ -101,6 +105,8 @@ N개의 레플리카를 가진 스테이트풀셋은 배포 시에 ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -112,8 +118,8 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에 -시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) +및 _Ready_ ([파드의 조건](/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 @@ -125,16 +131,17 @@ web-1 1/1 Running 0 18s ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 1m web-1 1/1 Running 0 1m - ``` [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. -이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 -고유한 순번에 기인한다. 파드의 이름의 형식은 +이 정체성은 스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에서 +각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은 `<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다. @@ -145,7 +152,9 @@ web-1 1/1 Running 0 1m [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` web-0 web-1 ``` @@ -157,7 +166,14 @@ web-1 ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +위 명령으로 새로운 셸을 시작한다. 새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 다음을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -172,6 +188,8 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` +(이제 `exit` 명령으로 컨테이너 셸에서 종료한다.) + 헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다 (Running과 Ready 상태의 각 파드마다 1개). SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다. @@ -196,6 +214,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -207,15 +227,27 @@ web-1 1/1 Running 0 34s ``` 파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 -`kubectl exec`과 `kubectl run`을 이용하자. +`kubectl exec`과 `kubectl run`을 이용하자. 먼저, 파드의 호스트네임을 확인한다. ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` web-0 web-1 - +``` +그리고 다음을 실행한다. +``` kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +이 명령으로 새로운 셸이 시작된다. +새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 이것을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -230,6 +262,8 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` +(이제 `exit` 명령으로 컨테이너 셸을 종료한다.) + 파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 @@ -255,12 +289,20 @@ Running과 Ready 상태의 모든 파드들을 ```shell kubectl get pvc -l app=nginx +``` +출력 결과는 다음과 비슷하다. +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 -묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 + +스테이트풀셋 컨트롤러는 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨" term_id="persistent-volume" >}}에 +묶인 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}을 생성했다. + +본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다. NGINX 웹서버는 기본 색인 파일로 @@ -272,23 +314,23 @@ NGINX 웹서버는 기본 색인 파일로 NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -it "web-$i" -- curl localhost; done +``` +``` web-0 web-1 ``` {{< note >}} -위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 -`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면 +다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 ([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). -```shell -for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done -``` +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` -위에 curl 명령을 재시도하기 전에 +위에 `curl` 명령을 재시도하기 전에 위 명령을 실행해야 한다. {{< /note >}} 첫째 터미널에서 스테이트풀셋의 파드를 감시하자. @@ -301,6 +343,8 @@ kubectl get pod -w -l app=nginx ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` @@ -309,6 +353,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -322,7 +368,9 @@ web-1 1/1 Running 0 34s 웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자. ``` -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -334,6 +382,7 @@ web-1 각각의 퍼시스턴트볼륨은 적절하게 마운트된다. ## 스테이트풀셋 스케일링 + 스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 @@ -352,6 +401,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl scale sts web --replicas=5 +``` +``` statefulset.apps/web scaled ``` @@ -360,6 +411,8 @@ statefulset.apps/web scaled ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2h web-1 1/1 Running 0 2h @@ -392,18 +445,22 @@ web-4 1/1 Running 0 19s kubectl get pods -w -l app=nginx ``` -다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 뒤로 - 3개의 레플리카로 스케일링하자. +다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 다시 +3개의 레플리카로 스케일링하자. ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` statefulset.apps/web patched ``` `web-4`와 `web-3`이 Terminating으로 전환되기까지 기다리자. -``` +```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3h web-1 1/1 Running 0 3h @@ -428,6 +485,8 @@ web-3 1/1 Terminating 0 42s ```shell kubectl get pvc -l app=nginx +``` +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h @@ -459,6 +518,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` statefulset.apps/web patched ``` @@ -467,13 +528,18 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` statefulset.apps/web patched ``` 다른 터미널창에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m web-1 1/1 Running 0 7m @@ -512,17 +578,20 @@ web-0 1/1 Running 0 10s 이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 그것이 Running과 Ready 상태로 전환될 때까지 기다린다. 알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 -다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. +다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 +복원한다는 것이다. + 업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 -이전 버전으로 복원한다. -이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 +이전 버전으로 복원한다. 이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 애플리케이션을 계속 건강하게 유지하고 업데이트도 일관되게 유지하려 한다. 컨테이너 이미지를 살펴보기 위해 파드를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 @@ -531,10 +600,13 @@ k8s.gcr.io/nginx-slim:0.8 스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다. -**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` +{{< note >}} +스테이트풀셋의 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` 명령어도 사용할 수 있다. +{{< /note >}} #### 단계적으로 업데이트 하기 {#staging-an-update} + `RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여 스테이트풀셋의 단계적으로 업데이트할 수 있다. 단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 @@ -544,6 +616,8 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` statefulset.apps/web patched ``` @@ -551,20 +625,26 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 파드를 삭제하자. ```shell -kubectl delete po web-2 +kubectl delete pod web-2 +``` +``` pod "web-2" deleted ``` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -572,12 +652,13 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -파드의 컨테이너를 가져오자. +파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 @@ -586,6 +667,7 @@ k8s.gcr.io/nginx-slim:0.8 `파티션`보다 작기 때문이다. #### 카나리(Canary) 롤링 아웃 + [위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다. @@ -593,13 +675,17 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` statefulset.apps/web patched ``` `web-2` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -611,6 +697,8 @@ web-2 1/1 Running 0 18s ```shell kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.7 ``` @@ -622,14 +710,19 @@ k8s.gcr.io/nginx-slim:0.7 `web-1` 파드를 삭제하자. ```shell -kubectl delete po web-1 +kubectl delete pod web-1 +``` +``` pod "web-1" deleted ``` `web-1` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 0/1 Terminating 0 6m @@ -643,12 +736,13 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드의 컨테이너를 가져오자. +`web-1` 파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` `web-1` 는 원래 환경설정으로 복원되었는데 @@ -658,6 +752,7 @@ k8s.gcr.io/nginx-slim:0.8 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 + [카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게 분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 수행할 수 있다. 단계적 롤아웃을 수행하려면 @@ -668,13 +763,18 @@ partition은 현재 `2`이다. partition을 `0`으로 바꾸자. ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 모든 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m web-1 0/1 ContainerCreating 0 11s @@ -692,17 +792,19 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` -파드의 컨테이너를 가져오자. +스테이트풀셋에 있는 파드의 컨테이너 이미지 상세 정보를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 ``` -`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 +`partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서 업데이트 처리를 하도록 허용하였다. ### 삭제 시 동작 @@ -733,6 +835,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web --cascade=false +``` +``` statefulset.apps "web" deleted ``` @@ -740,6 +844,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 1/1 Running 0 7m @@ -751,6 +857,8 @@ web-2 1/1 Running 0 5m ```shell kubectl delete pod web-0 +``` +``` pod "web-0" deleted ``` @@ -758,6 +866,8 @@ pod "web-0" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 10m web-2 1/1 Running 0 7m @@ -777,17 +887,21 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` statefulset.apps/web created service/nginx unchanged ``` 이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 -nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다. +_nginx_ 헤드리스 서비스를 생성하려고 했음을 뜻한다. 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 16m web-2 1/1 Running 0 2m @@ -813,7 +927,9 @@ web-2 0/1 Terminating 0 3m 다른 관점으로 살펴보자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -837,6 +953,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web +``` +``` statefulset.apps "web" deleted ``` 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 @@ -844,6 +962,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 11m web-1 1/1 Running 0 27m @@ -864,12 +984,17 @@ web-1 0/1 Terminating 0 29m 스테이트풀 컨트롤러는 이전 파드가 완전히 종료되기까지 기다린다. -스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 -삭제하지 않음을 주의하자. +{{< note >}} +종속적 삭제는 파드와 함께 스테이트풀셋을 제거하지만, +스테이트풀셋과 관련된 헤드리스 서비스를 삭제하지 않는다. 꼭 `nginx` 서비스를 수동으로 삭제해라. +{{< /note >}} + ```shell kubectl delete service nginx +``` +``` service "nginx" deleted ``` @@ -877,6 +1002,8 @@ service "nginx" deleted ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -885,22 +1012,30 @@ statefulset.apps/web created `index.html` 파일 내용을 검색하자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` 스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 -다시 생성되고 `web-0`과 `web-1`은 여전히 +다시 생성되고 `web-0`과 `web-1`은 계속 각 호스트네임을 제공한다. -최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다. +최종적으로 `web` 스테이트풀셋을 삭제한다. ```shell kubectl delete service nginx +``` +``` service "nginx" deleted - +``` +그리고 `nginx` 서비스를 삭제한다. +```shell kubectl delete statefulset web +``` +``` statefulset "web" deleted ``` @@ -934,13 +1069,15 @@ statefulset "web" deleted 터미널에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w ``` 다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자. ```shell kubectl apply -f web-parallel.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -948,7 +1085,9 @@ statefulset.apps/web created 첫째 터미널에서 실행했던 `kubectl get` 명령어의 출력을 살펴보자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -967,12 +1106,14 @@ web-1 1/1 Running 0 10s ```shell kubectl scale statefulset/web --replicas=4 +``` +``` statefulset.apps/web scaled ``` `kubectl get` 명령어를 실행 중인 터미널의 출력을 살펴보자. -```shell +``` web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 7s @@ -982,18 +1123,24 @@ web-3 1/1 Running 0 26s ``` -스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다. +스테이트풀셋은 두 개의 새 파드를 시작하였다. 두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다. -이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. +## {{% heading "cleanup" %}} + +정리의 일환으로 `kubectl` 명령을 실행할 준비가 된 두 개의 터미널이 열려 +있어야 한다. ```shell kubectl delete sts web +# sts는 statefulset의 약자이다. ``` -다시 한번 다른 터미널에서 실행 중인 `kubectl get`명령의 출력을 확인해보자. - +`kubectl get` 명령으로 해당 파드가 삭제된 것을 확인할 수 있다. ```shell +kubectl get pod -l app=nginx -w +``` +``` web-3 1/1 Terminating 0 9m web-2 1/1 Terminating 0 9m web-3 1/1 Terminating 0 9m @@ -1019,7 +1166,7 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 +삭제하는 동안, 스테이트풀셋은 모든 파드를 동시에 삭제한다. 해당 파드를 삭제하기 전에 그 파드의 순서상 후계자를 기다리지 않는다. `kubectl get` 명령어가 실행된 터미널을 닫고 @@ -1030,12 +1177,11 @@ kubectl delete svc nginx ``` -## {{% heading "cleanup" %}} - +{{< note >}} 이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 -퍼시스턴트 스토리지 미디어를 삭제해야 한다. +퍼시스턴트 스토리지 미디어도 삭제해야 한다. + + 모든 스토리지를 반환하도록 환경, 스토리지 설정과 프로비저닝 방법에 따른 단계를 따르자. - - - +{{< /note >}} diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 323a087408..1e0aefd4a3 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -190,8 +190,8 @@ kubectl apply -k ./ 응답은 아래와 비슷해야 한다. ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} @@ -237,7 +237,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. +* [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자. * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index bf4c2e179c..490f6ff18d 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -43,7 +43,7 @@ weight: 40 - 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. - + @@ -132,7 +132,7 @@ zk-2 1/1 Running 0 40s for i in 0 1 2; do kubectl exec zk-$i -- hostname; done ``` -스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`, +스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`, `zk-2`로 정한다. ```shell @@ -183,9 +183,9 @@ ZooKeeper는 그것의 애플리케이션 환경설정을 `zoo.cfg` 파일에 kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg ``` -아래 파일의 `server.1`, `server.2`, `server.3` 속성에서 -`1`, `2`, `3`은 ZooKeeper 서버의 `myid` 파일에 구분자와 -연관된다. +아래 파일의 `server.1`, `server.2`, `server.3` 속성에서 +`1`, `2`, `3`은 ZooKeeper 서버의 `myid` 파일에 구분자와 +연관된다. 이들은 `zk` 스테이트풀셋의 파드의 FQDNS을 설정한다. ```shell @@ -302,7 +302,7 @@ ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상 복제된 상태 머신을 이루는 합의 프로토콜에서 이용하는 일반적인 기법이다. -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령을 이용하여 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령을 이용하여 `zk` 스테이트풀셋을 삭제하자. ```shell @@ -448,7 +448,7 @@ ZooKeeper의 서버 디렉터리에 마운트한다. [리더 선출 촉진](#리더-선출-촉진)과 [합의 달성](#합의-달성) 섹션에서 알렸듯이, ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다. -또한 Zab 프로토콜의 일관된 설정도 +또한 Zab 프로토콜의 일관된 설정도 네트워크에 걸쳐 올바르게 동작하기 위해서 필요하다. 이 예시에서는 메니페스트에 구성을 직접 포함시켜서 일관된 구성을 달성한다. @@ -496,7 +496,7 @@ ZooKeeper는 [Log4j](http://logging.apache.org/log4j/2.x/)를 이용하며 kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties ``` -아래 로깅 구성은 ZooKeeper가 모든 로그를 +아래 로깅 구성은 ZooKeeper가 모든 로그를 표준 출력 스트림으로 처리하게 한다. ```shell @@ -544,7 +544,7 @@ kubectl logs zk-0 --tail 20 쿠버네티스는 더 강력하지만 조금 복잡한 로그 통합을 [스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)와 -[Elasticsearch와 Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. +[Elasticsearch와 Kibana](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. 클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다. @@ -564,7 +564,7 @@ securityContext: fsGroup: 1000 ``` -파드 컨테이너에서 UID 1000은 ZooKeeper 사용자이며, GID 1000은 +파드 컨테이너에서 UID 1000은 ZooKeeper 사용자이며, GID 1000은 ZooKeeper의 그룹에 해당한다. `zk-0` 파드에서 프로세스 정보를 얻어오자. @@ -866,7 +866,7 @@ kubernetes-node-2g2d kubectl get nodes ``` -[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 +[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자. ```shell @@ -1093,7 +1093,3 @@ node "kubernetes-node-ixsl" uncordoned 퍼시스턴트 스토리지 미디어를 삭제하자. 귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서 모든 스토리지가 재확보되도록 하자. - - - - diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 291cceba26..ec5ea3b53d 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -15,7 +15,7 @@ weight: 10 ## {{% heading "prerequisites" %}} - * [kubectl](/docs/tasks/tools/install-kubectl/)을 설치한다. + * [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. * Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여 쿠버네티스 클러스터를 생성한다. @@ -52,10 +52,10 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml 위의 명령어는 - [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) + [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 오브젝트와 관련된 - [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) - 오브젝트를 생성한다. 레플리카 셋은 다섯 개의 + [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + 오브젝트를 생성한다. 레플리카셋은 다섯 개의 [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며, 각 파드는 Hello World 애플리케이션을 실행한다. @@ -64,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml kubectl get deployments hello-world kubectl describe deployments hello-world -1. 레플리카 셋 오브젝트에 대한 정보를 확인한다. +1. 레플리카셋 오브젝트에 대한 정보를 확인한다. kubectl get replicasets kubectl describe replicasets @@ -160,7 +160,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml kubectl delete services my-service -Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면, +Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면, 아래의 명령어를 입력한다. kubectl delete deployment hello-world @@ -173,4 +173,3 @@ Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 [애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 배워 본다. - diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index cd8ff4e03f..9d5cf7713b 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -402,6 +402,6 @@ kubectl scale --replicas=3 deployment/frontend ## {{% heading "whatsnext" %}} * [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. -* [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다. +* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다. * [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. * [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 422ed877e2..cce67800a6 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -47,7 +47,7 @@ card: {{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} -1. 매니페스트 파일을 다운로드한 디렉토리에서 터미널 창을 시작한다. +1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다. 1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다. ```shell @@ -218,7 +218,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. ```shell - kubectl get services + kubectl get services ``` 결과는 아래와 같은 형태로 나타난다. @@ -320,7 +320,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 redis-slave-2005841000-fpvqc 1/1 Running 0 1h redis-slave-2005841000-phfv9 1/1 Running 0 1h ``` - + ## {{% heading "cleanup" %}} @@ -346,7 +346,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 deployment.apps "frontend" deleted service "frontend" deleted ``` - + 1. 파드의 목록을 질의하여 실행 중인 파드가 없는지 확인한다. ```shell @@ -367,5 +367,4 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 -* [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기 - +* [자원 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)에 대해 더 알아보기 diff --git a/content/ko/partners/_index.html b/content/ko/partners/_index.html index 2ac7e6945c..3bd6a375f2 100644 --- a/content/ko/partners/_index.html +++ b/content/ko/partners/_index.html @@ -7,79 +7,90 @@ cid: partners ---
    -
    -
    쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.
    -
    -
    -
    -
    - 공인 쿠버네티스 서비스 공급자(Kubernetes Certified Service Providers, KCSP) -
    -
    기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다. -


    - -

    KCSP에 관심이 있으신가요? -
    -
    -
    -
    -
    - 공인 쿠버네티스 배포, 호스트된 플랫폼 그리고 설치 프로그램 -
    소프트웨어 적합성은 모든 벤더의 쿠버네티스 버전이 필요한 API를 지원하도록 보장합니다. -


    - -

    공인 쿠버네티스에 관심이 있으신가요? -
    -
    -
    -
    -
    쿠버네티스 교육 파트너(Kubernetes Training Partners, KTP)
    -
    클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다. -



    - -

    KTP에 관심이 있으신가요? -
    -
    -
    - - + - -
    - - -
    - -
    + + +
    + + +
    + +