kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Mac で「スクリーンショット設定」を変更する(サムネイル / 影 / 保存場所)

最近 MacBook Pro を新しく移行をしたときに,個人的に必須な「スクリーンショット」関連の設定をした.頻度は低くても毎回調べていたので,今さらながらまとめておく.大きく3点ある!

f:id:kakku22:20210327154317p:plain

1. 画面右下に表示されるサムネイルを無効化する

デフォルト設定だと「スクリーンショット」を取得すると画面右下に数秒サムネイルが表示される.とても邪魔なので無効化する.なお「スクリーンショット」アプリケーションから設定する場合は「オプション」「フローティングサムネールを表示」OFF にすれば OK!

$ defaults write com.apple.screencapture show-thumbnail -bool FALSE

2. 影を無効化する

デフォルト設定だと「スクリーンショット」に影が付いてしまう.ブログに画像を添付するときに邪魔だし,画像サイズ(縦横)も微妙に増えてしまうため,無効化する.

$ defaults write com.apple.screencapture disable-shadow -bool true

3. 保存場所を変更する

デフォルト設定だと「デスクトップ」に全ての「スクリーンショット」が保存される.個人的に「デスクトップ」にファイルを置きたくなく,ブログ用素材として数日残しておくことも多いため,保存場所を変更する(僕は ~/Downloads/screenshots にしている).なお「スクリーンショット」アプリケーションから設定する場合は「オプション」「その他の場所」を設定すれば OK!

$ mkdir ~/Downloads/screenshots
$ defaults write com.apple.screencapture location ~/Downloads/screenshots

2021年2-3月に CKAD と CKA を受験した / 受験 Tips と 勉強方法をまとめる

2021年2-3月に Kubernetes の資格 CKAD (Certified Kubernetes Application Developer)CKA (Certified Kubernetes Administrator) を受験した.3年後に更新をするであろう自分のためにも勉強方法をまとめておく.当たり前だけど,出題に関する内容は書かず,受験 Tips と勉強方法にフォーカスする.なお,試験情報は以下に載っている.一言でまとめると「勉強過程も試験本番もとにかく楽しかったー🙌」かな!

www.cncf.io

www.cncf.io

カリキュラム(出題範囲)は GitHub に PDF として公開されている.

  • CKAD (Certified Kubernetes Application Developer)
    • 13% - Core Concepts
    • 10% - Multi-Container Pods
    • 20% - Pod Design
    • 8% - State Persistence
    • 18% - Configuration
    • 18% - Observability
    • 13% - Services & Networking
  • CKA (Certified Kubernetes Administrator)
    • 25% - Cluster Architecture, Installation & Configuration
    • 15% - Workloads & Scheduling
    • 20% - Services & Networking
    • 10% - Storage
    • 30% - Troubleshooting

github.com

1. 前提と結果 🐳

僕自身,試験を受験をする前から「Kubernetes チョットワカル」レベルだったと思う.具体的には技術講師として,研修で Kubernetes を教える機会もある.ただし,プロダクションワークロードでの大規模な運用経験はないし,Amazon EKS など,フルマネージド EKS クラスターを使うことも多く,知識に偏りはある.例えば,コントロールプレーン関連は詳しくなかったり.よって,操作に慣れている CKAD はほとんど勉強せずに受験したけど,CKA は苦手分野を重点的に勉強してから受験した.結果は以下の通り.

受験日 試験名 得点 結果 バージョン
2021/02/23 CKAD (Certified Kubernetes Application Developer) 93 点 合格 Kubernetes v1.20
2021/03/07 CKA (Certified Kubernetes Administrator) 88 点 合格 Kubernetes v1.20

2. 試験種別 : CKAD-JP や CKA-JP とは 🐳

試験を調べると「CKAD と CKAD-JP」「CKA と CKA-JP」など,日本語に対応した試験が出てくるため,気になる人もいると思う.あくまで「試験当日に試験監督員とのチャットコミュニケーションが日本語でできるかどうか」であり,試験自体の言語設定は試験種別に関係なく自由に変えられるし,合格後に発行される証明書も -JP になるわけではなく,個人的には些細な差だと思う.とは言え,不安があれば -JP で申し込んでおけば良いかと!最初よく理解していなかったこともあり,何も考えずに -JP を申し込んだ.

なお,CKA を受験したときは,日本語ではあるけど,用意されたテキストを一方的にペーストされ続けたり,機械翻訳だと推測できる意味不明な日本語が送られてきたりして,受験するモチベーションが下がるほどに対応が悪かった.別途フィードバックを送る予定.

3. 受験環境 🐳

リモート受験なので整理整頓されている部屋であることは大前提として,以下の環境で受験した.簡単にまとめておく!

最近は AWS 認定試験もリモート受験できるし,また僕自身が実際に経験したわけではないけど,Mac で Karabiner-Elements を使っているとリモート受験に悪影響を及ぼすという情報もあったりするため,基本的に Chrome をインストールする以外はデフォルト設定のままにした MacBook Pro をリモート受験専用に準備してある.また macOS は Big Sur でも問題なく受験できた.

  • MacBook Pro(リモート受験専用)
    • Big Sur
  • HHKB Professional Type-S
  • Magic Trackpad 2
  • サブディスプレイ(Kubernetes ドキュメント参照用)

なお,試験画面 (Exam User Interface) のイメージはドキュメントに載っている.引用して載せておく.基本的にストレスなく使えるけど,残り数分で焦っているときに高速で vim 操作をしていたりすると「遅い!遅いぞ!」と感じる場面はあった.

Exam User Interface - T&C DOCS (Candidate Facing Resources) より引用

4. 個人的な CKAD / CKA 受験 Tips 🐳

4-1. alias k=kubectl

僕自身はもう kubectl ではなく,無意識に k と入力してしまう体になっているため,試験開始と同時に「エイリアス」「コマンド補完」を設定した.コマンドを覚えておく必要はなく,kubectl Cheat Sheet のコマンドをそのままコピペすれば OK!

kubernetes.io

4-2. ブックマーク

ドキュメント「Important Instructions: CKA and CKAD」に書いてある通り,試験画面とは別に「1タブ」を開くことができる.基本的には Kubernetes ドキュメントを開くと思うけど,正式に許可されているドメインは3種類ある.日本語に翻訳された https://kubernetes.io/ja/docs/ も問題なく見れる.ただし,Community Forums https://discuss.kubernetes.io/ は禁止されていて,ドキュメント検索結果には出てくるため,闇雲に検索していると,禁止サイトを開いてしまう危険性もある.だからこそ,確認する可能性のあるドキュメントはブックマークに入れておく.

  • https://kubernetes.io/docs/
  • https://github.com/kubernetes/
  • https://kubernetes.io/blog/

use their Chrome or Chromium browser to open one additional tab in order to access assets at: https://kubernetes.io/docs/, https://github.com/kubernetes/, https://kubernetes.io/blog/ and their subdomains. This includes all available language translations of these pages (e.g. https://kubernetes.io/zh/docs/) No other tabs may be opened and no other sites may be navigated to (including https://discuss.kubernetes.io/).

また,ドキュメントの中に上記ドメイン以外の外部リンクも含まれているため,気を付ける必要がある.全ては受験者の責任となる旨もドキュメントに明記されている.

The allowed sites above may contain links that point to external sites. It is the responsibility of the candidate not to click on any links that cause them to navigate to a domain that is not allowed.

docs.linuxfoundation.org

4-3. Chrome プロファイル

個人的に使っている Google アカウントは,多くの拡張機能やブックマークを設定しているため,試験で使う不安もあり,専用の Chrome プロファイルを用意した.上記のブックマークだけを設定しておけば良くて便利だと思う!

4-4. kubectl -h | grep kubectl

kubectl コマンドのオプションを kubectl -h で確認しながらコマンドを作っていくと,予想以上に時間を浪費してしまう.そこで,以下のように kubectl -h の結果から「コマンド例」を雛形として取得して,ここから修正をしていくと,効率的に進められる.特に時間的に追い込まれる CKAD で使える Tips だと思う.

$ kubectl run -h | grep kubectl
$ kubectl create deployment -h | grep kubectl
$ kubectl create configmap -h | grep kubectl
$ kubectl expose -h | grep kubectl
$ kubectl scale -h | grep kubectl

「コマンド例」は,kubectl Command Reference の右側にも載っているため,ドキュメントから取得する場合は以下をブックマークしておくこともできる.個人的にはスピード重視で kubectl -h | grep kubectl を使ったけど!

kubernetes.io

5. CKAD 勉強方法 🐳

5-1. GitHub : dgkanatsios/CKAD-exercises

受験体験記事を読んでいると,必ずと言っても良いほどに紹介されている「dgkanatsios/CKAD-exercises」リポジトリを2回試した.CKAD を受験しないとしても,kubectl コマンドの操作に慣れるためのコンテンツとして有用だと思う.少し気になった点はプルリクエストを送って,貢献することができた.

なお,Issue なども出ているけど,回答例に多く載っている --restart=Never の必要性に関しては,現状の Kubernetes v1.20 で受験するなら,基本的には不要と言える.kubectl run --restart の値によって PodDeployment を作ることができたため,意図的に Pod を作る目的だけど,Kubernetes v1.18 から考慮する必要がなくなった(正確には generators 関連).

github.com

5-2. Katacoda : CKAD Practice Challenge

無料で試せる Katacoda「CKAD Practice Challenge」も1回試した.サンプル回答も載っているし,Kubernetes クラスターを構築する必要もないし,気軽に試せる点にメリットを感じる.

www.katacoda.com

5-3. A Cloud Guru : Certified Kubernetes Application Developer (CKAD)

最後は A Cloud Guru「Certified Kubernetes Application Developer (CKAD)」も少し試した.講義ビデオはほとんど見てなく,復習をしておきたかった部分だけ「HANDS-ON LAB」という演習機能を使った.

acloud.guru

6. CKA 勉強方法 🐳

6-1. Udemy : Certified Kubernetes Administrator (CKA) with Practice Tests

受験体験記事を読んでいると,よく紹介されている Udemy「Certified Kubernetes Administrator (CKA) with Practice Tests」を購入した.苦手分野の講義ビデオを見たり,「Practice Test」「Mock Exams」という演習機能を使った.定価だと購入するのを躊躇するレベルではあるけど,定期的にセールをしているし,調べればクーポンコードも発行されているため,1500円程度なら良いかなと!

www.udemy.com

6-2. A Cloud Guru : Certified Kubernetes Administrator (CKA)

CKAD と同じく,A Cloud Guru「Certified Kubernetes Administrator (CKA)」も試した.苦手分野の講義ビデオを見つつ,ほとんどは「HANDS-ON LAB」という演習機能を使った.座学的な部分はドキュメントもあるし,書籍もあるし,無理に講義ビデオを見る必要はないと思う.やはり,手軽に試せる Kubernetes クラスターがあることに安心感がある.

acloud.guru

6-3 : GitHub : Kubernetes Network Policy Recipes

個人的に Network Policy に苦手意識があったため,GitHub に公開されている「Kubernetes Network Policy Recipes」を参考にした.詳しくは紹介ブログを書いてある.

kakakakakku.hatenablog.com

6-4 : GitHub : David-VTUK/CKA-StudyGuide

「David-VTUK/CKA-StudyGuide」 リポジトリには,CKA のカリキュラム(出題範囲)をより具体的にリストアップした「RevisionTopics」というコンテンツがあり,全体像と自分自身の知識を比較しながら「どこから勉強すれば良いか?」を確認できて良かった.例えば,CoreDNSCNI だったり,トラブルシューティング時に使えるコマンド例も整理できる.

github.com

6-5 : CKA Self-Study Course

RX-M という企業のサイトに載っている「CKA Self-Study Course」も,CKA のカリキュラム(出題範囲)をより具体的に整理するために便利だった.「David-VTUK/CKA-StudyGuide」 リポジトリよりも「操作」を重視している印象もあり,特に RBAC 関連のコマンド例を整理できた.また最後には「Practice Drill」というクイズも載っているため,理解度確認にも使える.少し誤植もあり,修正したかったけど,GitHub リポジトリなどは見つけられなかった.

rx-m.com

まとめ 🐳

2021年2-3月に Kubernetes の資格 CKAD (Certified Kubernetes Application Developer)CKA (Certified Kubernetes Administrator) を受験した.勉強過程も試験本番もとにかく楽しかったー🙌

残るは CKS (Certified Kubernetes Security Specialist) を受験するぞー!試験問題の日本語化を待ちたい気持ちもあるけど...!

参考記事 🐳

試験を受験することを考える前から読んでいたため,試験前にパラパラと見返す程度ではあったけど「Kubernetes 完全ガイド 第2版」も読んでおくべし!とは言え,情報量は多くなるため,逆引きリファレンス的に活用すると良いと思う.またカリキュラム(出題範囲)にも入っている Multi-Container Pods の理解を深めるなら「分散システムデザインパターン」も参考になる.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

そして,勉強する Kubernetes クラスターをお手軽に構築するなら kind も使える.合わせて読んでもらえると!

kakakakakku.hatenablog.com

追記

2022年4月に CKS (Certified Kubernetes Security Specialist) にも合格した!詳しくは以下の記事にまとめたー🎉

kakakakakku.hatenablog.com

kube-capacity コマンドを使って Pod のリソース値をノード別にシンプルに表示する

Kubernetes では Pod にリソース値(要求 : Requests と 制限 : Limits)を設定できる.設定値は kubectl describe コマンドを使って確認できるし,使用率は kubectl top コマンドを使って確認できるけど,今回紹介する CLI「kube-capacity」を使うと,Pod のリソース値(設定値と使用率)をまとめてシンプルに表示できる.最近使っていて便利なのでメモも兼ねて紹介する.

github.com

検証環境

インストール

「kube-capacity」HomebrewKrew を使ってインストールできる.Homebrew だと kube-capacity コマンドとなり,Krew だと kubectl resource-capacity コマンドとなる.どちらも試したけど,今回は新しいバージョン (0.5.0) が使える Homebrew を使う.

$ brew tap robscott/tap
$ brew install robscott/tap/kube-capacity

$ kube-capacity version
kube-capacity version 0.5.0

$ kubectl krew install resource-capacity
Installed plugin: resource-capacity

$ kubectl resource-capacity version
kube-capacity version 0.4.0

1. kube-capacity コマンドを実行する

まず,kind で構築した検証用 Kubernetes クラスターで kube-capacity コマンドを実行すると,ノードごとに以下の値が表示される.* の行には全てのノードの合計値が表示される.

  • CPU REQUESTS : CPU 要求 (Requests) 合計値 と 割合
  • CPU LIMITS : CPU 制限 (Limits) 合計値 と 割合
  • MEMORY REQUESTS : Memory 要求 (Requests) 合計値 と 割合
  • MEMORY LIMITS : Memory 制限 (Limits) 合計値 と 割合
$ kube-capacity
NODE                 CPU REQUESTS   CPU LIMITS   MEMORY REQUESTS   MEMORY LIMITS
*                    1150m (9%)     300m (2%)    390Mi (6%)        490Mi (8%)
kind-control-plane   950m (23%)     100m (2%)    290Mi (14%)       390Mi (19%)
kind-worker          100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-worker2         100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)

最初は表示されている 950m (23%)100m (2%) という値の裏付けが取れずに悩んだけど,デフォルトでは kube-system Namespace の値も含めて全ての Pod が対象になっている.そこで kube-capacity コマンドの --pods オプションを使って Pod レベルで表示すると,CoreDNSkube-apiserverkindnet の合計であると確認できる.

$ kube-capacity --pods
NODE                 NAMESPACE            POD                                          CPU REQUESTS   CPU LIMITS   MEMORY REQUESTS   MEMORY LIMITS
*                    *                    *                                            1150m (9%)     300m (2%)    390Mi (6%)        490Mi (8%)

kind-control-plane   *                    *                                            950m (23%)     100m (2%)    290Mi (14%)       390Mi (19%)
kind-control-plane   kube-system          coredns-74ff55c5b-5v6b8                      100m (2%)      0 (0%)       70Mi (3%)         170Mi (8%)
kind-control-plane   kube-system          coredns-74ff55c5b-xp5m7                      100m (2%)      0 (0%)       70Mi (3%)         170Mi (8%)
kind-control-plane   kube-system          etcd-kind-control-plane                      100m (2%)      0 (0%)       100Mi (5%)        0 (0%)
kind-control-plane   kube-system          kindnet-lbslz                                100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-control-plane   kube-system          kube-apiserver-kind-control-plane            250m (6%)      0 (0%)       0 (0%)            0 (0%)
kind-control-plane   kube-system          kube-controller-manager-kind-control-plane   200m (5%)      0 (0%)       0 (0%)            0 (0%)
kind-control-plane   kube-system          kube-proxy-25ltm                             0 (0%)         0 (0%)       0 (0%)            0 (0%)
kind-control-plane   kube-system          kube-scheduler-kind-control-plane            100m (2%)      0 (0%)       0 (0%)            0 (0%)
kind-control-plane   local-path-storage   local-path-provisioner-78776bfc44-cxcpk      0 (0%)         0 (0%)       0 (0%)            0 (0%)

kind-worker          *                    *                                            100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-worker          kube-system          kindnet-7t5kc                                100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-worker          kube-system          kube-proxy-kbzl8                             0 (0%)         0 (0%)       0 (0%)            0 (0%)
kind-worker          kube-system          metrics-server-8bbfb4bdb-qrrls               0 (0%)         0 (0%)       0 (0%)            0 (0%)

kind-worker2         *                    *                                            100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-worker2         kube-system          kindnet-ptmng                                100m (2%)      100m (2%)    50Mi (2%)         50Mi (2%)
kind-worker2         kube-system          kube-proxy-vws54                             0 (0%)         0 (0%)       0 (0%)            0 (0%)

2. Namespace を指定して kube-capacity コマンドを実行する

kube-system Namespace を無視して,特定の Namespace を指定することもできる.kube-capacity コマンドの --namespace-labels オプションを使って NamespaceLabel で指定する.今回は name=sandbox という適当な Label を付けた sandbox Namespace を作った.初期状態だとまだ何もリソースを適用していないため,全て 0 (0%) になっている.

$ kube-capacity --pods --namespace-labels name=sandbox
NODE                 NAMESPACE   POD   CPU REQUESTS   CPU LIMITS   MEMORY REQUESTS   MEMORY LIMITS
*                    *           *     0 (0%)         0 (0%)       0 (0%)            0 (0%)

kind-control-plane   *           *     0 (0%)         0 (0%)       0 (0%)            0 (0%)

kind-worker          *           *     0 (0%)         0 (0%)       0 (0%)            0 (0%)

kind-worker2         *           *     0 (0%)         0 (0%)       0 (0%)            0 (0%)

3. Deployment を適用して値を確認する

検証用に以下のようなリソース値(要求 : Requests と 制限 : Limits)を設定した Deploymentreplicas: 4 で作る.

  • requests
    • cpu : 200m
    • memory : 100Mi
  • limits
    • cpu : 1000m
    • memory : 500Mi
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-kube-capacity-nginx
  namespace: sandbox
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19-alpine
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 500m
            memory: 500Mi
        ports:
        - containerPort: 80

Deployment を適用してから,もう1度 kube-capacity コマンドを実行すると,設定したリソース値の合計になっていた.便利!

$ kube-capacity --pods --namespace-labels name=sandbox
NODE                 NAMESPACE   POD                                            CPU REQUESTS   CPU LIMITS    MEMORY REQUESTS   MEMORY LIMITS
*                    *           *                                              400m (3%)      2 (16%)       400Mi (6%)        2000Mi (33%)

kind-control-plane   *           *                                              0 (0%)         0 (0%)        0 (0%)            0 (0%)

kind-worker          *           *                                              100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)
kind-worker          sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-8csj7   100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)

kind-worker2         *           *                                              300m (7%)      1500m (37%)   300Mi (15%)       1500Mi (75%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-5mxnx   100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-6gwts   100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-bbnsj   100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)

4. 追加で使用率も表示する

さらに kube-capacity コマンドの --util オプションを使うと「使用率」を表示できるようになる.

  • CPU UTIL : CPU 使用率
  • MEMORY UTIL : Memory 使用率
$ kube-capacity --pods --namespace-labels name=sandbox --util
NODE                 NAMESPACE   POD                                            CPU REQUESTS   CPU LIMITS    CPU UTIL          MEMORY REQUESTS   MEMORY LIMITS   MEMORY UTIL
*                    *           *                                              400m (3%)      2 (16%)       517975675n (4%)   400Mi (6%)        2000Mi (33%)    854872Ki (13%)

kind-control-plane   *           *                                              0 (0%)         0 (0%)        396547620n (9%)   0 (0%)            0 (0%)          558568Ki (27%)

kind-worker          *           *                                              100m (2%)      500m (12%)    62508437n (1%)    100Mi (5%)        500Mi (25%)     158572Ki (7%)
kind-worker          sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-8csj7   100m (2%)      500m (12%)    0 (0%)            100Mi (5%)        500Mi (25%)     3960Ki (0%)

kind-worker2         *           *                                              300m (7%)      1500m (37%)   58919618n (1%)    300Mi (15%)       1500Mi (75%)    137732Ki (6%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-5mxnx   100m (2%)      500m (12%)    0 (0%)            100Mi (5%)        500Mi (25%)     3948Ki (0%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-6gwts   100m (2%)      500m (12%)    0 (0%)            100Mi (5%)        500Mi (25%)     3980Ki (0%)
kind-worker2         sandbox     sandbox-kube-capacity-nginx-68fdb47b8d-bbnsj   100m (2%)      500m (12%)    0 (0%)            100Mi (5%)        500Mi (25%)     4124Ki (0%)

5. オプションは他にもある

今回は --namespace-labels オプションを使ったけど,オプションは他にもある.例えば --pod-labels オプションを使えば,PodLabel で絞り込みできるし,--node-labels オプションを使えば,ノードの Label で絞り込みできる.

$ kube-capacity --pod-labels app=nginx
NODE                 CPU REQUESTS   CPU LIMITS    MEMORY REQUESTS   MEMORY LIMITS
*                    400m (3%)      2 (16%)       400Mi (6%)        2000Mi (33%)
kind-control-plane   0 (0%)         0 (0%)        0 (0%)            0 (0%)
kind-worker          100m (2%)      500m (12%)    100Mi (5%)        500Mi (25%)
kind-worker2         300m (7%)      1500m (37%)   300Mi (15%)       1500Mi (75%)

$ kube-capacity --node-labels kubernetes.io/os=linux
NODE                 CPU REQUESTS   CPU LIMITS    MEMORY REQUESTS   MEMORY LIMITS
*                    1550m (12%)    2300m (19%)   790Mi (13%)       2490Mi (41%)
kind-control-plane   950m (23%)     100m (2%)     290Mi (14%)       390Mi (19%)
kind-worker          200m (5%)      600m (15%)    150Mi (7%)        550Mi (27%)
kind-worker2         400m (10%)     1600m (40%)   350Mi (17%)       1550Mi (77%)

まとめ

「kube-capacity」を使うと,Pod のリソース値をノード別にシンプルに表示できる.インストールしておくと便利!なお,今はまだリリースされていないけど,GitHub リポジトリの master ブランチを見ると,新しく --namespace オプションが追加されている.Label を使わずにシンプルに Namespace を指定できるため,今よりも便利になると思う.

github.com

Network Policy をわかりやすく学べる「Kubernetes Network Policy Recipes」

GitHub に公開されている「Kubernetes Network Policy Recipes」を使うと,Kubernetes の Network Policy をわかりやすく学べる.現時点だと「計14種類」Network Policy レシピ(サンプル)が載っていて,実際に使う機会がありそうな設定も多くて参考になる.さらに Network Policy の YAML を読むだけだとイメージしにくかったりする Ingress と EgressAllow と Deny の関係性も図解されているのも素晴らしい!

github.com

レシピ一覧

現時点で公開されているレシピをまとめる.日本語訳は参考程度に載せておく!

  • Basics
    • DENY all traffic to an application(アプリケーションへの全てのトラフィックを拒否する)
    • LIMIT traffic to an application(アプリケーションへのトラフィックを制限する)
    • ALLOW all traffic to an application(アプリケーションへの全てのトラフィックを許可する)
  • Namespaces
    • DENY all non-whitelisted traffic in the current namespace(現在の Namespace でホワイトリストに登録されていない全てのトラフィックを拒否する)
    • DENY all traffic from other namespaces(他の Namespace からの全てのトラフィックを拒否する)
    • ALLOW traffic to an application from all namespaces(全ての Namespace からアプリケーションへのトラフィックを許可する)
    • ALLOW all traffic from a namespace(Namespace からの全てのトラフィックを許可する)
    • ALLOW traffic from some pods in another namespace(他の Namespace の一部の Pod からのトラフィックを許可する)
  • Serving External Traffic
    • ALLOW traffic from external clients(外部クライアントからのトラフィックを許可する)
  • Advanced
    • ALLOW traffic only to certain port numbers of an application(アプリケーションの特定のポート番号へのトラフィックのみを許可する)
    • ALLOW traffic from apps using multiple selectors(複数のセレクターを使ってアプリケーションからのトラフィックを許可する)
  • Controlling Outbound (Egress) Traffic
    • DENY egress traffic from an application(アプリケーションからの外向きのトラフィックを拒否する)
    • DENY all non-whitelisted egress traffic in a namespace(現在の Namespace でホワイトリストに登録されていない全ての外向きのトラフィックを拒否する)
    • LIMIT egress traffic to the cluster(クラスターへの外向きのトラフィックを制限する)

検証環境

「Kubernetes Network Policy Recipes」の紹介も兼ねて,レシピをいくつか試してみる.今回は以下の検証環境を前提にする.なお,レシピ(手順書)に含まれている kubectl run コマンドの --generator=run-pod/v1 オプションは特に必要なく,コマンドは一部変えている.

  • Kubernetes : v1.20.1
  • Calico : v3.14.2

DENY all traffic to an application(アプリケーションへの全てのトラフィックを拒否する)

f:id:kakku22:20210314141402g:plain
GitHub - ahmetb/kubernetes-network-policy-recipes より引用

「DENY all traffic to an application」レシピでは,Label app=web を持ったアプリケーション Pod へのトラフィックを拒否する.さっそく試していく!まず,default NamespaceLabel app=web を持ったアプリケーション PodService を作る.

$ kubectl run web --image nginx --labels app=web --expose --port 80
service/web created
pod/web created

次にアプリケーション Pod に対してリクエストを送る Poddefault Namespace に作る(図だと右側にある Any container).Pod の中で wget コマンドを実行すると,正常に nginx に接続できる.

$ kubectl run --rm -it --image alpine test-$RANDOM -- sh

/ # wget -qO- http://web
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
(中略)
</html>

ここで Network Policy を作る.ポイントは大きく2点ある.

  • spec.podSelector : Network Policy を適用する対象(Label app=web を持つ Pod
  • spec.ingress : 許可する Ingress ルール(全て拒否)
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-deny-all
spec:
  podSelector:
    matchLabels:
      app: web
  ingress: []

動作確認をするため,もう1度 wget コマンドを実行すると,タイムアウトになった.期待通りに Network Policy が適用されている.

$ kubectl run --rm -it --image alpine test-$RANDOM -- sh

/ # wget -qO- --timeout=2 http://web
wget: download timed out

DENY all traffic from other namespaces(他の Namespace からの全てのトラフィックを拒否する)

f:id:kakku22:20210314141329g:plain
GitHub - ahmetb/kubernetes-network-policy-recipes より引用

「DENY all traffic from other namespaces」レシピでは,他の Namespace からのトラフィックを拒否する.さっそく試していく!まず,さっきと同じように default NamespaceLabel app=web を持ったアプリケーション PodService を作る.

$ kubectl run web --image nginx --labels app=web --expose --port 80
service/web created
pod/web created

次に Network Policy を作る.ポイントは大きく3点ある.

  • metadata.namespace : Network Policy を適用する Namespace(今回は default
  • spec.podSelector : Network Policy を適用する対象(指定なし = default Namespace の全ての Pod
  • spec.ingress : 許可する Ingress ルール(default Namespace の全ての Pod を許可)
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: default
  name: deny-from-other-namespaces
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

動作確認をするため,今回は default NamespacePodfoo NamespacePod のそれぞれから wget コマンドを実行する(図だと左側にある any pod と中央下にある app=db).同じ default Namespace からは正常に接続できて,別の foo Namespace からはタイムアウトになった.期待通りに Network Policy が適用されている.

$ kubectl run test-$RANDOM --namespace=default --rm -it --image alpine -- sh

/ # wget -qO- --timeout=2 http://web.default
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

$ kubectl run test-$RANDOM --namespace=foo --rm -it --image alpine -- sh

/ # wget -qO- --timeout=2 http://web.default
wget: download timed out

ALLOW traffic only to certain port numbers of an application(アプリケーションの特定のポート番号へのトラフィックのみを許可する)

f:id:kakku22:20210314141250g:plain
GitHub - ahmetb/kubernetes-network-policy-recipes より引用

「ALLOW traffic only to certain port numbers of an application」レシピでは,特定のポートへのトラフィックを許可する.さっそく試していく!まず「5000 ポート」「8000 ポート」を許可したサンプルイメージ ahmet/app-on-two-ports を使って default NamespacePod を作る.さらに「5001 ポート」「8001 ポート」にマッピングをした Service を作る.

$ kubectl run apiserver --image ahmet/app-on-two-ports --labels app=apiserver
pod/apiserver created

$ kubectl create service clusterip apiserver \
    --tcp 8001:8000 \
    --tcp 5001:5000
service/apiserver created

次に Network Policy を作る.ポイントは大きく2点ある.

  • spec.podSelector : Network Policy を適用する対象(Label app=apiserver を持つ Pod
  • spec.ingress : 許可する Ingress ルール(Label role=monitoring を持つ Pod から 5000 ポートへの接続を許可)
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow-5000
spec:
  podSelector:
    matchLabels:
      app: apiserver
  ingress:
  - ports:
    - port: 5000
    from:
    - podSelector:
        matchLabels:
          role: monitoring

さっそく動作確認をしていく.まず,Label role=monitoring を持たない Pod の中で wget コマンドを実行すると「5001 (5000) ポート」「8001 (8000) ポート」もタイムアウトになる.

$ kubectl run test-$RANDOM --rm -it --image alpine -- sh


/ # wget -qO- --timeout=2 http://apiserver:5001/metrics
wget: download timed out

/ # wget -qO- --timeout=2 http://apiserver:8001
wget: download timed out

次に,Label role=monitoring を持つ Pod の中で wget コマンドを実行すると「5001 (5000) ポート」に接続できる.「8001 (8000) ポート」はタイムアウトになる.期待通りに Network Policy が適用されている.

$ kubectl run test-$RANDOM --rm -it --image alpine --labels role=monitoring -- sh

/ # wget -qO- --timeout=2 http://apiserver:5001/metrics
http.requests=1
go.goroutines=5
go.cpus=2

/ # wget -qO- --timeout=2 http://apiserver:8001
wget: download timed out

まとめ

「Kubernetes Network Policy Recipes」を使うと,Kubernetes の Network Policy をわかりやすく学べる.また Certified Kubernetes Administrator (CKA)Certified Kubernetes Application Developer (CKAD)Certified Kubernetes Security Specialist (CKS) の対策にも使える!Network Policy の YAML に苦手意識があったら(まさに僕!)試してみると良いのではないでしょうか!

github.com

マニフェストを適用する前に編集できる "kubectl create --edit" コマンド

Kubernetes のドキュメントを読んでいたら kubectl create コマンドで --edit オプションが使えると書いてあった.kubectl create -h コマンドでヘルプを確認したところ Edit the API resource before creating と書いてある.簡単に言うと kubectl create コマンドでマニフェストを適用する前に編集できる.今まで使ったことがなく試してみた!

You can use kubectl create --edit to make arbitrary changes to an object before it is created. Here's an example:
$ kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client > /tmp/srv.yaml
$ kubectl create --edit -f /tmp/srv.yaml

kubernetes.io

kubectl create --edit コマンドをさっそく試す

適当に nginx イメージを replicas: 3 で設定した Deployment のマニフェスト (deployment.yaml) を準備して,以下のように kubectl create --edit -f deployment.yaml コマンドを実行する.すると kubectl edit コマンドと同じようにエディタ画面になり,適用する前にマニフェストを編集できる.

$ kubectl create --edit -f deployment.yaml

f:id:kakku22:20210305110209p:plain

今回は replicas: 3replicas: 5 に編集した.なるほど!編集できた.

$ kubectl get pods
NAME                            READY   STATUS    RESTARTS   AGE
sandbox-nginx-f9f7485cd-2xqx7   1/1     Running   0          5m
sandbox-nginx-f9f7485cd-6fm5n   1/1     Running   0          5m
sandbox-nginx-f9f7485cd-mnpz2   1/1     Running   0          5m
sandbox-nginx-f9f7485cd-qhgtp   1/1     Running   0          5m
sandbox-nginx-f9f7485cd-w5pml   1/1     Running   0          5m

kubectl create --edit コマンドの使いどころ

基本的には kubectl apply コマンドを使う機会が多いと思う.今回試した kubectl create --edit コマンドの使いどころを考えていたら,別のドキュメントに以下のように書いてあった.確かに「チュートリアル」など,一時的に試すときには便利そう.今までは wget で取得してから一部を編集していたことが多かったし!

Suppose you have the URL of an object configuration file. You can use kubectl create --edit to make changes to the configuration before the object is created. This is particularly useful for tutorials and tasks that point to a configuration file that could be modified by the reader.

kubernetes.io

当然だけど,マニフェストを GitHub 経由 (GitHub : kakakakakku/k8s-manifests) で取得して kubectl create --edit コマンドを実行しても結果は同じ.マニフェストを編集してから適用できる.

$ kubectl create --edit -f https://raw.githubusercontent.com/kakakakakku/k8s-manifests/master/sandbox-kubectl-create-edit-option/deployment.yaml
deployment.apps/sandbox-nginx created

まとめ

今まで使ったことがなかった kubectl create --edit コマンドを試した.手元にあるマニフェストを適用する前に編集できて便利な使いどころもありそう!そもそも kubectl create コマンドを使う機会は仕事だと多くはなく,1番使うのは Certified Kubernetes Administrator (CKA)Certified Kubernetes Application Developer (CKAD) を受験するときかもしれないけど!w