現状のAWS認定資格の有効期限は取得から3年間ですが、数年単位で時間が空くと毎回調べたことを忘れてしまいますので、次回から調べなくても良いよう今回調べた内容を書き留めておきます。
AWS再認定時の疑問ズバリそれは、再認定時に更新される認定期間についてです。
いつも、どっちだっけ？と調べているような気がします。
正解は【 2. 再認定受験して合格した日から3年間 】です。
再認定の公式サイトに以下のように記載されています。
AWS による認定は、取得した日から 3 年間有効となります。
確かにAWS認定アカウントの画面で確認してみたらそうなってますね。
例：AWS Certified DevOps Engineer - Professional
2020-11-29：初回取得
↕ 認定期間 #1
2023-11-11：再認定取得
↕ 認定期間 #2
2026-11-11：有効期限
今回の調査で参考にした情報です。
以前Mercuryで作成した日の出・日の入を計算するWebアプリに
以下の警告が出力されるようになってしまいました。
<ipython-input-1-511780b4e84b>:98: MatplotlibDeprecationWarning: The plot_date function was deprecated in Matplotlib 3.9 and will be removed in 3.11. Use plot instead. plt.plot_date(x_dates, y_sr_times, markersize=1, color='darkorange') <ipython-input-1-511780b4e84b>:99: MatplotlibDeprecationWarning: The plot_date function was deprecated in Matplotlib 3.9 and will be removed in 3.11. Use plot instead. plt.plot_date(x_dates, y_ss_times, markersize=1, color='darkblue') <ipython-input-1-511780b4e84b>:115: MatplotlibDeprecationWarning: The plot_date function was deprecated in Matplotlib 3.9 and will be removed in 3.11. Use plot instead. plt.plot_date(x_dates, y_daytimes, markersize=1, color='darkorange')
ぜんぜん難しい内容ではありませんが正直めんどくさいなぁと思い試しにGeminiに丸投げしたらサクッと修正してくれました（笑） しかも日本語で優しく丁寧に教えてくれます。
一旦 Jupyter Notebook （Google Colab）で修正コードを確認して動作確認したうえで、再度 Mercury Cloud にデプロイ（アップロード）して最終確認してみます。
ちゃんと修正されてますね。よしよし👍
https://daytime.runmercury.com/app/sample
まだ修正内容の妥当性や最終的なチェックをする必要はありますが、この程度の修正はもう人間がやる必要ない世界なんですね。素晴らしい👏
毎回調べるのが面倒なので、よく使用するk8sのリソースのデフォルト値を表にまとめました。
今回の対象リソースは以下3種類で、k8sの基本中の基本のリソースです。
以下の表はすべてオブジェクトの spec 配下の設定のデフォルト値です。
| 設定項目 | デフォルト値 | ||||
|---|---|---|---|---|---|
| ports | protocol | TCP | |||
| type | ClusterIP | ||||
| sessionAffinity | None | ||||
| externalTrafficPolicy | Cluster | ||||
| internalTrafficPolicy | Cluster | ||||
| sessionAffinityConfig | clientIP | timeoutSeconds | 10800 | ||
| allocateLoadBalancerNodePorts | true | ||||
参照：
| 設定項目 | デフォルト値 | ||||
|---|---|---|---|---|---|
| replicas | 1 | ||||
| minReadySeconds | 0 | ||||
| strategy | type | RollingUpdate | |||
| rollingUpdate | maxSurge | 25% | |||
| maxUnavailable | 25% | ||||
| revisionHistoryLimit | 10 | ||||
| progressDeadlineSeconds | 600 | ||||
| paused | false | ||||
参照：
| 設定項目 | デフォルト値 | ||||
|---|---|---|---|---|---|
| enableServiceLinks | true | ||||
| tolerations | operator | Equal | |||
| preemptionPolicy | PreemptLowerPriority | ||||
| topologySpreadConstraints | maxSkew | 1 | |||
| whenUnsatisfiable | DoNotSchedule | ||||
| restartPolicy | Always | ||||
| terminationGracePeriodSeconds | 30 | ||||
| setdostnameAsFQDN | false | ||||
| dnsPolicy | ClusterFirst | ||||
| hostNetwork | false | ||||
| hostPID | false | ||||
| hostIPC | false | ||||
| shareProcessNamespace | false | ||||
| securityContext | (empty) | ||||
| hostUsers | true | ||||
| containers / initContainers / ephemeralContainers |
imagePullPolicy | Always | |||
| ports | protocol | TCP | |||
| volumeMounts | mountPropagation | None | |||
| readOnly | false | ||||
| recursiveReadOnly | None | ||||
| subPatd | "" (volume's root) | ||||
| subPatdExpr | "" (volume's root) | ||||
| resources | resizePolicy[] | restartPolicy | NotRequired | ||
| terminationMessagePatd | /dev/termination-log | ||||
| terminationMessagePolicy | File | ||||
| securityContext | procMount | Default | |||
| privileged | false | ||||
| readOnlyRootFilesystem | false | ||||
| stdin | false | ||||
| stdinOnce | false | ||||
| tty | false | ||||
| lifecycle | postStart / preStop |
httpGet | scheme | HTTP | |
| livenessProbe / readinessProbe / startupProbe |
httpGet | scheme | HTTP | ||
| periodSeconds | 10 | ||||
| timeoutSeconds | 1 | ||||
| failuretdreshold | 3 | ||||
| successtdreshold | 1 | ||||
参照：
先日CKADを再取得した際、Deploymentのラベルの扱いについて再認識したことがあったので備忘メモを残しておきます。
よく見るDeploymentの例では、以下の例のようなラベル（★印）が定義されています。
例：controllers/nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx ←★任意：このリソース（Deployment）のラベル
spec:
replicas: 3
selector:
matchLabels:
app: nginx ←★必須：Deploymentが管理するPodのラベル ・・・【A】
template:
metadata:
labels:
app: nginx ←★必須：このリソース（Deployment）配下のPodのラベル ・・・【B】
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
それぞれのラベルの意味はkubernetes公式ドキュメント Deployment | Kubernetes にも記載されており【任意／必須】も含めて上記のような役割を担っています。
必須の【A】と【B】は省略できず、例えば以下のようなパターンではapply時にエラーとなりリソースを生成できません。（A ⊈ B）
The Deployment "nginx-deployment" is invalid:
* spec.selector: Required value
* spec.template.metadata.labels: Invalid value: map[string]string{"app":"nginx"}: `selector` does not match template `labels`
The Deployment "nginx-deployment" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string(nil), MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: empty selector is invalid for deployment
The Deployment "nginx-deployment" is invalid: spec.template.metadata.labels: Invalid value: map[string]string(nil): `selector` does not match template `labels`
The Deployment "nginx-deployment" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"xxxxx"}: `selector` does not match template `labels`
ラベルは複数定義できるため、厳密にすべてのラベルが完全に一致している必要があるかと言えばそうではありません。
以下のようなパターンはリソースを生成できます。（A ⊆ B）
定義：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
age: fifty
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
をapplyすると以下のように問題なくリソース作成できます。
kubectl apply -f deploy.yaml deployment.apps/nginx-deployment created kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-7f5b4c8c69-k458q 1/1 Running 0 27s age=fifty,app=nginx,pod-template-hash=7f5b4c8c69 nginx-deployment-7f5b4c8c69-kb6n2 1/1 Running 0 27s age=fifty,app=nginx,pod-template-hash=7f5b4c8c69 nginx-deployment-7f5b4c8c69-vkrlh 1/1 Running 0 27s age=fifty,app=nginx,pod-template-hash=7f5b4c8c69
※こんなことする人は居ないと思いますが試しにやってみました。（key重複は後勝ちなんですね😅）
定義：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: xxxxx
app: yyyyy
app: zzzzz
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
をapplyすると以下のように問題なくリソース作成できます。
kubectl apply -f deploy.yaml deployment.apps/nginx-deployment created kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-647677fc66-8lrnr 1/1 Running 0 12s app=nginx,pod-template-hash=647677fc66 nginx-deployment-647677fc66-gchpd 1/1 Running 0 12s app=nginx,pod-template-hash=647677fc66 nginx-deployment-647677fc66-shcvh 1/1 Running 0 12s app=nginx,pod-template-hash=647677fc66
k8sのリソースまわりは公式ドキュメントなどを読んでもイマイチ正しく理解できたかいつもモヤモヤしてしまいます。 今回のように試験勉強でハマったり気になったりしたことは実際に手を動かしてコマンドを叩いて検証するのが一番スッキリしますし、 単に機械的に資格を取得するための学習だけをするのは非常にもったいないので、学びの機会として今後もうまく利用していきたいところです。
今回は以下の情報を参考にさせてもらいました。🙇♂️
直近またk8sのお仕事をすることになったのと Certified Kubernetes Security Specialist (CKS) の有効期限が切れる前に一度 Kubestronaut の称号（と限定ジャケット）をゲットしておきたかったので 認定Kubernetesアプリケーション開発者 (CKAD-JP) を再取得することにしました。結果としてはCKADを再取得することには成功したのですが、 Kubestronaut の称号を得ることには失敗しました。これまでの受験では発生しなかったトラブルが何度も発生したので、後学＆備忘録として経緯を記録しておこうと思います。
本日（2025年4月27日）時点ではLinux Foundationが認定するKubernetesの認定資格は、次の５種類（KCNA/KCSA/CKA/CKAD/CKS）があります。また、2024年3月から新たに Kubestronautプログラム なるものが開始されており、これら5種類を全冠した人に与えられる新たな称号です。k8sエンジニアのコレクター心理をくすぐるいやらしい戦略ですね（笑）
今回、改めて認定有効期間の最新動向を調べてみましたが昨年アナウンスされた
2024 年認定有効期限ポリシーの変更 - Linux Foundation - トレーニング
2024年4月1日から全ての認定期間が24ヶ月（2年）に変更されている点 から変更はありませんでした。
そして、ご存じの通り認定試験の価格も順調に値上げされており、このようなアナウンスがでておりました。（ま、これはいつものことですね…💸）
2025年2月4日よりCKA、CKAD、CKS、LFCS 認定試験の価格変更のお知らせ - The Linux Foundation
| 略称 | 正式名 | 概要 |
|
Kubernetesと広範なクラウド ネイティブ エコシステムに関する基本的な知識とスキルを証明する（有効認定期間：2年間） | |
|
Kubernetesクラスタのベースラインセキュリティ設定を理解し、セキュリティ制御の強化/テストと監視/脅威と脆弱性の強化に参加し、コンプライアンス目標を達成できるスキルを証明します（有効認定期間：2年間） | |
|
Kubernetes管理者の責任を遂行するスキル、知識、および能力を備えていることを保証する（有効認定期間：2年間） | |
|
ユーザーが Kubernetes 用のクラウドネイティブ アプリケーションを設計、構築、デプロイできることを証明する（有効認定期間：2年間） | |
|
Kubernetesの熟練した実践者（CKA認定が必要）であり、コンテナベースのアプリケーションやKubernetesプラットフォームの構築、デプロイ、ランタイム時のセキュリティを確保するための幅広いベストプラクティス能力を実証する（有効認定期間：2年間） |
今回の試験対策で実践した内容は主に次の２つです。
2019年に購入した教材を再利用したので今回新たに教材を購入しませんでした。なんと嬉しいことに最新動向に追従して教材がちゃんとアップデートされていました。これはありがたいですね。
Kubernetes Certified Application Developer (CKAD) Training | Udemy
主に以下の模擬試験的な教材を中心に実際に手を動かして繰り返し復習しました。
セクション12→11の順に実施する理由は、セクション11の方が難易度が高いためです。こちらの過去記事にも記載していますので併せてご覧ください。
試験を申し込むと教材として利用できるようになります。
Killer Shell - Exam Simulators
主に以下の模擬試験的な教材を中心に実際に手を動かして繰り返し復習しました。
こちらの教材には有効期限があるので模擬試験として利用する場合はタイミングを考慮して利用しましょう。ただ、模擬試験として利用する有効期限が過ぎても解答と解説は閲覧することができます。目的に応じてうまく活用しましょう。
今回の受験で実際に起きたことを時系列に沿って記載すると以下のような感じです。
| # | 日時 | 事象 |
|
1 |
2025年04月06日（日） 10:00～10:30 |
★ 受験（1回目）：無効 試験開始後30分で PSI Secure Browser がフリーズして試験が強制終了する |
| 2 |
2025年04月06日（日） 10:36 |
終了後すぐに http://trainingsupport.linuxfoundation.org/ でサポートへチケットを起票する |
| 3 |
2025年04月08日（火） 20:32 |
採点中（Grading in progress）のまま48時間以上経過してもサポートから回答がないので起票したチケットにコメントを追記する |
| 4 |
2025年04月09日（水） 12:10 |
採点中（Grading in progress）のまま72時間以上経過してもサポートから回答がないので起票したチケットにコメントを追記する |
| 5 |
2025年04月09日（水） 17:52 |
サポートから再度受験が可能となった旨の連絡がくる |
| 6 |
2025年04月11日（金） 04:00～04:30 |
★ 受験（2回目）：無効 事前にPCスペックやネットワーク帯域などを入念にチェックして試験に臨むも再び試験開始後30分で PSI Secure Browser がフリーズして試験が強制終了する |
| 7 |
2025年04月11日（金） 10:20 |
終了後しばらく様子を見つつ http://trainingsupport.linuxfoundation.org/ でサポートへチケットを起票する |
| 8 |
2025年04月16日（水） 23:13 |
採点中（Grading in progress）のまま1週間近く経過してもサポートから回答がないので起票したチケットにコメントを追記する |
| 9 |
2025年04月17日（木） 00:00 |
CKSの資格を失効する（このタイミングで Kubestronaut になる資格を喪失する） |
| 10 |
2025年04月17日（木） 18:44 |
あまりにもサポートから回答がないので心配になって起票したチケットに更に催促のコメントを追記する |
| 11 |
2025年04月17日（木） 19:47 |
サポートから再度受験が可能となった旨の連絡がくる |
| 12 |
2025年04月20日（日） 16:00～18:00 |
★ 受験（3回目）：不合格 受験時に使用するPCを再セットアップ（OS再インストール）して受験したところ PSI Secure Browser がフリーズすることなく受験が完了する（試験結果は不合格だったが、最後まで受験できたことに安心する） |
| 13 |
2025年04月25日（金） 04:30～06:30 |
☆ 受験（4回目）：合格 PSI Secure Browser がフリーズすることなく受験が完了する |
今回のトラブルに対処するためネットに有益な情報がないか検索（例：PSI Secure Browser、フリーズ、など）してみたところ、数は多くはないものの、似たような事象で困っている人は一定数いそうでした。
CKA・CKAD受験記(PSI Secure Browser版)[2023/01] - sec_solfa’s blog
いずれも、これといった有効な解決策はないようで、とにかく気長にサポートとキャッチボールをしながら、受験する環境を変えて原因の切り分けをするというアプローチしか無さそうです。（こうなると試験センターで受験するという選択肢も欲しいですね）
今回は初回受験から受験終了まで20日（3週間弱）を要しました。目論見としては、CKSの資格を失効する2025年4月17日（木）までに、ギリギリ2回（初回受験＋リテイク）受験して合格するというスケジュールで臨んだのですが完全に計画が破綻してしまいました。これまでの受験では今回のようなトラブルには遭遇したことがなかったので、まさかここまで時間がかかるとは想像もしていませんでしたが、今後は今回のようなトラブルが発生することも念頭に置きながら計画を立てて臨む必要があると痛感しました。加えて、サポートとのキャッチボールのリードタイムも想像より長い印象でした。特に２回目フリーズ時は催促して1週間くらいだったので、もし強めの催促をしなかったらもっと放置された可能性も高かったように思います。
なるべく今回のようなトラブルに遭遇したくなかったので、過去に受験で使用した実績のあるPCを利用して受験に臨んだのですが、残念なトラブルに見舞われてしまいました。最終的にPCを再セットアップ（OS再インストール）して受験することで試験を完了させることができたので、少なくともネットワーク帯域やH/Wの問題ではなく、OSにインストールされている何らかのソフトウェアが影響していた可能性が高いことまでは分りましたが詳細は不明です。試験センターで受験できないスタイルの資格試験なので、難しいとは思いますが受験前のシステムチェックなどでもう少し厳密にチェックして事前に教えてほしいところです。
今回は基本的には問題文を日本語の表示で受験しましたが、途中明らかにおかしな問題文があり、英語の表示に切り替えたところ、問題文の原文（英語）の多くが無視され欠落した意味の分からない問題がありました。問題文のタグ名が
undefined: undefined
と明らかに不自然な表示になっていたので気付けましたが、自動翻訳の怖いところです。多言語対応しているとはいえ、翻訳後の問題文のチェックはあまりされていない前提で試験に臨むのが良さそうです。
結局今回は Kubestronaut になることはできませんでした。CKSを再取得するモチベーションが湧けば改めて挑戦したいと思いますが、なかなか手間もお金もかかることなのでもう少し考えてから決めたいと思います。それでは一旦お疲れさまでした🙇♂️
こちらも先日の技書博で購入した本です。
前回記事の前に読んだ本なのですが、こちらについても学びのメモを残しておきます。
個人的に参考になったと感じた点について以下に簡単にまとめておきます。
本書の用語の定義
| 用語 | 説明 |
|---|---|
| OAuth | OAuth2.0 のこと |
| OAuth の仕様 | RFC6749 のこと |
| OIDC の仕様 | OpenID Connect Core 1.0 のこと |
以下の３点の意味を理解できていること
OAuth は権限委譲のプロトコルです。 認可のプロトコルとも言われます。 OAuth によって、ユーザーのリソースへのアクセス権限をサードパーティのアプリに委譲できます。 しかも、サードパーティアプリにはリソースオーナーのID・パスワードを教える必要はありません。
OAuth 2.0のグラントタイプ（Authorization Grant）には4種類のグラントタイプ（※OIDCではフローと呼ぶ）がある。
本書ではOAuth 認証とOIDC（OpenID Connect）に関係する前者2つのグラントタイプ（認可コード、インプリシット）について解説している。
OAuth は権限委譲のためのプロトコルです。 （中略） ここには「アプリへのログインのためにユーザーを認証する」という話は出てきません。 OAuth はアプリの認証のためのプロトコルではないからです。 話がややこしいのはリソースサーバーとしてプロフィール情報を提供するAPIがある場合です。 本書では以降、このようなAPIを「プロフィールAPI」と呼びます。 アプリはこのプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になります。 これがいわゆる「OAuth 認証」です。
仕組みの視点においては以下のとおり。
【OIDC】＝【OAuth】＋【IDトークン】＋【UserInfoエンドポイント】
OAuth と OIDC で用語が異なることに加え、OIDC でも複数の呼び方が混在していてややこしい。🥺
| 対象 | OAuth | OIDC |
|---|---|---|
| 利用者 | リソースオーナー | エンドユーザー |
| アプリ | クライアント | リライング・パーティ |
| トークン発行 | 認可サーバー | IDプロバイダ ／ オープンIDプロバイダ （IdP：Identity Provider／OP：OpenID Provider） |
| 情報取得 | リソースサーバー （様々なリソース） |
UserInfoエンドポイント （プロフィール情報のみ） |
OAuth では「グラントタイプ」と呼んでいたものは、OIDC では「フロー」と呼ぶ。
「グラントタイプ」と「フロー」の対応は以下のとおり。
| グラントタイプ ／ フロー | OAuth | OIDC |
|---|---|---|
| 認可コード | ◯：あり | ◯：あり |
| インプリシット | ◯：あり | ◯：あり |
| リソースオーナーパスワード | ◯：あり | Ｘ：なし |
| クライアントクレデンシャル | ◯：あり | Ｘ：なし |
| ハイブリッド | ◯：あり | ◯：あり |
つきつめると、OAuth と OIDC のシーケンスの違いは IDトークン の発行の有無と言っても過言ではない。
OAuth 認証では、プロフィールAPIの情報でエンドユーザーの認証をする。
OIDC では、IDトークンでエンドユーザーの認証をする。
IDトークンの形式は、署名付きの JWT（JSON Web Token：ジョット）です。
OIDC は OAuth の仕様を認証で利用できるように拡張したもの。
途中までそれぞれの団体（OAuth1.0：IETF と OpenID2.0：OpenID Foundation）により策定されていたプロトコルが
といった状況が見えてきた段階で両者が合流、協力しながら進めることになった。
第３章のコラム（P.33）で
「OAuth 認証」という言葉はなぜ使わないほうがよいのか
で、
本書では「OAuth ＋ プロフィールAPI」による認証を「OAuth 認証」と呼んでいますが、「OAuth 認証」を規定した仕様があるわけではありません。すなわち「OAuth 認証」の定義があるわけではなく、皆が好き勝手に「OAuth 認証」という言葉を使っているにすぎません。
（中略）
不用意な誤解が広がるのを防ぐために、読者のみなさんも「OAuth 認証」という言葉はできるだけ使わないようにしましょう。
と記載されているのですが、こちらの本の中では使われまくっていたのが気になりました。
できれば本書の中で体現してほしかったなと感じましたが、もしかしたら、書き上げた後で気づいてコラムを追加したのかもしれないですね。
先日の技書博で購入した本をハンズオンしてみました。
Githubに実践メモを残したのでこちらをご参照ください。
偽書博ではシリーズ3冊まとめて購入しました。
左の2冊は既読ですが右の1冊はまだ積読状態なので後ほど読みたいと思います。
ちなみに、まとめ買いしたらこんなステッカーもセットでいただきました。どこに貼ればよいのだろうか…
