Merge pull request #47152 from Okabe-Junya/fix-author-in-blog

[ja] Update blog content files to move author details in front-matter

Author: k8s-ci-robot

content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -3,11 +3,20 @@ layout: blog
 title: "Don't Panic: Kubernetes and Docker"
 date: 2020-12-02
 slug: dont-panic-kubernetes-and-docker
+author: >
+  Jorge Castro,
+  Duffie Cooley,
+  Kat Cosgrove,
+  Justin Garrison,
+  Noah Kantrowitz,
+  Bob Killen,
+  Rey Lejano,
+  Dan "POP" Papandrea,
+  Jeffrey Sica,
+  Davanum "Dims" Srinivas
 ---
 
-**著者:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
-
-Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。 
+Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。
 
 **パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。**
 
@@ -20,7 +29,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
 
 もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど)
 
-## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 
+## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。
 ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。
 
 お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。
@@ -32,7 +41,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co
 
 1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。
 
-## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 
+## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。
 
 この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。
 みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。

content/ja/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md

@@ -3,10 +3,10 @@ layout: blog
 title: "Kubernetesにおけるフォレンジックコンテナチェックポイント処理"
 date: 2022-12-05
 slug: forensic-container-checkpointing-alpha
+author: >
+  Adrian Reber (Red Hat)
 ---
 
-**Authors:** Adrian Reber (Red Hat)
-
 フォレンジックコンテナチェックポイント処理は[Checkpoint/Restore In Userspace](https://criu.org/) (CRIU)に基づいており、コンテナがチェックポイントされていることを認識することなく、実行中のコンテナのステートフルコピーを作成することができます。
 コンテナのコピーは、元のコンテナに気づかれることなく、サンドボックス環境で複数回の分析やリストアが可能です。
 フォレンジックコンテナチェックポイント処理はKubernetes v1.25でalpha機能として導入されました。

content/ja/blog/_posts/2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md

@@ -3,11 +3,12 @@ layout: blog
 title: "Kubernetes 1.26: PodDisruptionBudgetによって保護された不健全なPodに対する退避ポリシー"
 date: 2023-01-06
 slug: "unhealthy-pod-eviction-policy-for-pdbs"
+author: >
+  Filip Křepinský (Red Hat),
+  Morten Torkildsen (Google),
+  Ravi Gudimetla (Apple)
 ---
 
-**著者:** Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple)
-
-
 アプリケーションの中断がその可用性に影響を与えないようにすることは、簡単な作業ではありません。
 先月リリースされたKubernetes v1.26では、[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets) (PDB) に
 _不健全なPodの退避ポリシー_ を指定して、ノード管理操作中に可用性を維持できるようになりました。

content/ja/blog/_posts/2023-03-10-forensic-container-analysis/index.md

@@ -3,10 +3,10 @@ layout: blog
 title: "フォレンジックコンテナ分析"
 date: 2023-03-10
 slug: forensic-container-analysis
+author: >
+  Adrian Reber (Red Hat)
 ---
 
-**Authors:** Adrian Reber (Red Hat)
-
 前回投稿した[Kubernetesにおけるフォレンジックコンテナチェックポイント処理][forensic-blog]では、Kubernetesでのチェックポイントの作成や、それがどのようにセットアップされ、どのように使用されるのかを紹介しました。
 機能の名前はフォレンジックコンテナチェックポイントですが、Kubernetesによって作成されたチェックポイントの実際の分析方法については、詳細を説明しませんでした。
 この記事では、チェックポイントがどのように分析されるのかについての詳細を提供します。

content/ja/blog/_posts/2024-01-15-SIG-Release-Spotlight/index.md

@@ -3,10 +3,10 @@ layout: blog
 title: "SIG Releaseスポットライト(リリース・チーム・サブプロジェクト)"
 date: 2024-01-15
 slug: sig-release-spotlight-2023
+author: >
+  Nitish Kumar
 ---
 
-**筆者:** Nitish Kumar
-
 リリース・スペシャル・インタレスト・グループ(SIG Release)は、Kubernetesが4ヶ月ごとに最先端の機能とバグ修正でその刃を研ぐ場所です。Kubernetesのような大きなプロジェクトが、新バージョンをリリースするまでのタイムラインをどのように効率的に管理しているのか、またリリースチームの内部はどのようになっているのか、考えたことはありますか？このような疑問に興味がある方、もっと知りたい方、SIG Releaseの仕事に関わりたい方は、ぜひ読んでみてください！
 
 SIG ReleaseはKubernetesの開発と進化において重要な役割を担っています。その主な責任は、Kubernetesの新バージョンのリリースプロセスを管理することです。[通常3〜4ヶ月ごと](https://www.kubernetes.dev/resources/release/)の定期的なリリースサイクルで運営されています。このサイクルの間、Kubernetesリリースチームは他のSIGやコントリビューターと密接に連携し、円滑でうまく調整されたリリースを保証します。これには、リリーススケジュールの計画、コードフリーズとテストフェーズの期限の設定、バイナリ、ドキュメント、リリースノートなどのリリース成果物の作成が含まれます。

content/ja/blog/_posts/2024-01-23-image-filesystem.md

@@ -3,10 +3,10 @@ layout: blog
 title: 'Kubernetesでコンテナを別ファイルシステムに格納する設定方法'
 date: 2024-01-23
 slug: kubernetes-separate-image-filesystem
+author: >
+  Kevin Hannon (Red Hat)
 ---
 
-**著者:** Kevin Hannon (Red Hat)
-
 **翻訳者:** Taisuke Okamoto (IDC Frontier Inc), Junya Okabe (University of Tsukuba), nasa9084 (LY Corporation)
 
 Kubernetesクラスターの稼働、運用する上でよくある問題は、ディスク容量が不足することです。

content/ja/blog/_posts/2024-02-22-k8s-book-club/index.md

@@ -1,8 +1,10 @@
-------
+---
 layout: blog
 title: "Kubernetesブッククラブを覗く"
 slug: k8s-book-club
 date: 2024-02-22
+author: >
+  Frederico Muñoz (SAS Institute)
 ---
 
 **著者**: Frederico Muñoz (SAS Institute)

content/ja/blog/_posts/2024-03-07-cri-o-seccomp-oci-artifacts.md

@@ -3,10 +3,10 @@ layout: blog
 title: "CRI-O: OCIレジストリからのseccompプロファイルの適用"
 date: 2024-03-07
 slug: cri-o-seccomp-oci-artifacts
+author: >
+  Sascha Grunert
 ---
 
-**著者:** Sascha Grunert
-
 **翻訳者:** Taisuke Okamoto (IDC Frontier Inc), atoato88 (NEC Corporation), Junya Okabe (University of Tsukuba)
 
 seccompはセキュアなコンピューティングモードを意味し、Linuxカーネルのバージョン2.6.12以降の機能として提供されました。

content/ja/blog/_posts/2024-03-12-mid-cycle-1.30.md

@@ -2,10 +2,14 @@
 layout: blog
 title: 'Kubernetes v1.30をそっと覗く'
 date: 2024-03-12
+author: >
+  Amit Dsouza,
+  Frederick Kautz,
+  Kristin Martin,
+  Abigail McCarthy,
+  Natali Vlatko
 ---
 
-**著者:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko
-
 ## Kubernetes v1.30のおもしろい変更点をざっと見る
 
 新しい年であり、新しいKubernetesのリリースです。

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

@@ -3,10 +3,10 @@ layout: blog
 title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)"
 slug: diy-create-your-own-cloud-with-kubernetes-part-1
 date: 2024-04-05T07:30:00+00:00
+author: >
+  Andrei Kvapil (Ænix)
 ---
 
-**著者:** Andrei Kvapil (Ænix)
-
 **翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
 
 Ænixでは、Kubernetesに対する深い愛着があり、近いうちにすべての最新テクノロジーがKubernetesの驚くべきパターンを活用し始めることを夢見ています。