k8s 問題集・練習問題クイズ

k8sで、Podの望ましいレプリカ数を維持しローリングアップデートを扱う代表的なリソースはどれですか？

答え： Deployment

DeploymentはReplicaSetを介してPod数を維持し、ローリングアップデートやロールバックを扱う実務で最もよく使うワークロードです。

k8sで、Podへ安定した仮想IPやDNS名を提供して通信先を抽象化するリソースはどれですか？

答え： Service

ServiceはPodの入れ替わりに関係なく、ラベルセレクタに一致するPod群への安定した到達点を提供します。

k8sで、アプリ設定値などの非機密データをPodに渡す用途に適したリソースはどれですか？

答え： ConfigMap

ConfigMapは設定ファイルや環境変数など、機密でない設定データをコンテナに渡すために使います。

k8sで、パスワードやトークンなどの機密情報を扱うリソースはどれですか？

答え： Secret

Secretは機密情報を扱うためのリソースです。実務では外部Secret管理やRBAC、暗号化設定も合わせて考えます。

k8sのlivenessProbeの主な目的はどれですか？

答え： コンテナが生存しているか確認し、異常なら再起動させる

livenessProbeはアプリが固まった場合などにコンテナ再起動を促すためのヘルスチェックです。readinessProbeとは役割が違います。

k8sで、HTTP/HTTPSのホスト名やパスに基づいてServiceへルーティングする入口として使うものはどれですか？

答え： Ingress

IngressはHTTP/HTTPSの外部入口を定義します。実際に動かすにはIngress Controllerが必要です。

k8sで、Podに付与する実行時のIDとしてRBACやクラウド連携に使われるものはどれですか？

答え： ServiceAccount

ServiceAccountはPodがAPIや外部クラウドリソースにアクセスする際のIDとして扱われます。

現在のNamespaceにあるPodの状態を一覧で確認したい。まず使う基本コマンドとして適切なものはどれですか？

答え： kubectl get pods

kubectl get pods は現在のNamespaceのPod一覧とREADY、STATUS、RESTARTSなどを確認する基本コマンドです。障害調査の入口としてよく使います。

特定Podが起動失敗している。イベント、環境変数、ボリューム、Probe設定などの詳細を確認したい。適切なコマンドはどれですか？

答え： kubectl describe pod <pod名>

kubectl describe pod はPodの詳細、コンテナ状態、直近イベントなどを表示します。ImagePullBackOffやProbe失敗などの原因調査に向いています。

アプリコンテナの標準出力ログを確認したい。単一コンテナPodで基本的に使うコマンドはどれですか？

答え： kubectl logs <pod名>

kubectl logs <pod名> はPod内コンテナのログを表示します。複数コンテナPodでは -c <コンテナ名> を指定して対象を明確にします。

Pod内で一時的にシェルを開き、ファイルや環境変数を確認したい。一般的な実行コマンドはどれですか？

答え： kubectl exec -it <pod名> -- sh

kubectl exec はコンテナ内でコマンドを実行します。-it は対話操作向けで、-- の後にコンテナ内で実行するコマンドを指定します。

修正したDeploymentマニフェスト deployment.yaml をクラスタに反映したい。宣言的管理として適切なコマンドはどれですか？

答え： kubectl apply -f deployment.yaml

kubectl apply -f はYAMLなどのマニフェストをクラスタへ宣言的に反映します。差分を継続管理する前提の運用でよく使います。

特定Namespace dev のPod一覧を確認したい。適切なコマンドはどれですか？

答え： kubectl get pods -n dev

Namespaceを指定するには -n または --namespace を使います。--context は接続先クラスタやユーザーなどのkubectl contextを切り替える指定です。

Deployment web のレプリカ数を一時的に3へ変更したい。適切なコマンドはどれですか？

答え： kubectl scale deployment web --replicas=3

kubectl scale はDeploymentやReplicaSetなどのレプリカ数を変更します。GitOps運用では、恒久変更はマニフェスト側にも反映する必要があります。

Deployment api の更新が正常に進んでいるか、ロールアウト状態を確認したい。適切なコマンドはどれですか？

答え： kubectl rollout status deployment/api

kubectl rollout status deployment/api はDeploymentのロールアウト進行状況を確認します。更新が止まっている場合の初期確認に便利です。

不要になったNamespace sandbox を削除したい。含まれるリソースもまとめて削除される点に注意しながら実行するコマンドはどれですか？

答え： kubectl delete namespace sandbox

kubectl delete namespace sandbox はNamespaceを削除します。Namespace内の多くのリソースも削除対象になるため、対象環境を確認してから実行します。

操作前に、kubectlが現在どのクラスタ・ユーザー・Namespaceを向いているか確認したい。適切なコマンドはどれですか？

答え： kubectl config current-context と kubectl config view --minify

kubectl config current-context は現在のcontext名を表示します。kubectl config view --minify は現在contextに絞ったcluster、user、namespaceなどの設定確認に使えます。

Podの配置判断に必要なCPU量をSchedulerへ伝え、同時にコンテナが使えるCPUの上限も設定したい。指定する組合せはどれですか？

答え： requestsとlimits

requestsはスケジューリング時に必要量として使われ、limitsはコンテナが利用できるリソース上限を定めます。

アプリの起動は完了したが、依存DBへの接続が切れて一時的にリクエストを処理できない。Podを再起動せずServiceの転送先から外したい。使うProbeはどれですか？

答え： readinessProbe

readinessProbeが失敗するとPodは準備未完了となり、通常はServiceの転送対象から外れますが、コンテナは再起動されません。

DeploymentのPod数をCPU使用率に応じて自動的に増減させたい。代表的に利用するリソースはどれですか？

答え： HorizontalPodAutoscaler

HorizontalPodAutoscalerはCPU使用率などのメトリクスを基に、対象ワークロードのレプリカ数を調整します。

Nodeメンテナンスのdrain中も、WebアプリのPodを最低2個は利用可能に保ちたい。設定するものはどれですか？

答え： PodDisruptionBudgetのminAvailable

PodDisruptionBudgetはdrainなどの自発的な中断で同時に利用不能にできるPod数を制約します。障害による停止そのものは防ぎません。

あるNamespaceで、明示的に許可した通信以外はPodへの受信を拒否する方針にしたい。基本となる方法はどれですか？

答え： default-denyのNetworkPolicyを作り、必要な通信を別Policyで許可する

NetworkPolicy対応CNIを前提に、Podを選択する受信default-denyを設定し、必要な送信元やポートだけを追加Policyで許可します。

Kubernetesアプリを複数のマニフェストとしてまとめ、値を差し替えながら再利用可能に配布したい。Helmで中心になる単位はどれですか？

答え： Chart

Helm ChartはKubernetesリソースのテンプレートや既定値をまとめたパッケージです。環境差分はvaluesで調整し、同じChartを複数環境へ展開できます。

同じHelm Chartをdevとprodに展開するが、prodだけレプリカ数やイメージタグを変えたい。一般的に編集・指定するものはどれですか？

答え： values.yaml または追加のvaluesファイル

HelmではChart内のテンプレートに値を埋め込みます。環境別の差分はvalues.yaml、別valuesファイル、--setなどで指定します。

リポジトリにあるChartを初めてクラスタへ展開し、Helmのリリースとして管理したい。基本コマンドはどれですか？

答え： helm install

helm installは指定したChartからリソースを作成し、名前付きのリリースとして履歴管理します。repo updateはローカルのChart索引更新だけです。

既存のHelmリリースを新しいChartバージョンやvaluesで更新したい。使うコマンドはどれですか？

答え： helm upgrade

helm upgradeは既存リリースを指定したChartと値で更新します。必要に応じて--installを付けると未作成時にインストールもできます。

HelmのテンプレートがどのKubernetesマニフェストに展開されるか、クラスタへ適用せず事前確認したい。適切なのはどれですか？

答え： helm template

helm templateはChartをローカルでレンダリングし、生成されるYAMLを表示します。CIでの確認やレビューにも使えます。

Helmリリースの更新に失敗した場合、直前の正常なリビジョンへ戻したい。使うコマンドはどれですか？

答え： helm rollback

helm rollbackはリリース履歴の指定リビジョンへ戻します。対象リビジョンを判断するにはhelm historyで履歴を確認します。

Helm Chart内で、APIバージョンやアプリバージョンなどChart自体のメタデータを記述するファイルはどれですか？

答え： Chart.yaml

Chart.yamlはChart名、バージョン、appVersionなどChartのメタデータを持ちます。values.yamlはテンプレートへ渡す既定値を持ちます。

Helmリリースを削除し、Chartから作成されたKubernetesリソースも通常は削除したい。使うコマンドはどれですか？

答え： helm uninstall

helm uninstallは指定リリースをアンインストールし、通常はそのリリースが管理していたKubernetesリソースを削除します。

一時的にNodeへ新しいPodを配置させず、既存Podはすぐには退避しないようにしたい。使うkubectl操作はどれですか？

答え： kubectl cordon

cordonはNodeをSchedulingDisabledにし、新しいPodの配置対象から外します。既存Podを退避させるにはdrainを使います。

DeploymentのPodを設定変更なしで順番に作り直し、アプリを再起動させたい。代表的なコマンドはどれですか？

答え： kubectl rollout restart deployment/<name>

kubectl rollout restartはPodテンプレートに再起動用の変更を加え、Deploymentのローリング更新としてPodを作り直します。

Deploymentの新バージョン展開が途中で止まっていないか確認したい。進行状況の確認に使う代表的なコマンドはどれですか？

答え： kubectl rollout status deployment/<name>

rollout statusはDeploymentなどのロールアウト完了や進行状況を確認します。失敗時はdescribeやlogsで原因を追います。

NamespaceごとにCPUやメモリの合計使用量を制限し、チーム単位の使いすぎを防ぎたい。使うリソースはどれですか？

答え： ResourceQuota

ResourceQuotaはNamespace内で作成できるリソース数やCPU・メモリ要求量などの合計に上限を設定します。

PodがKubernetes APIへアクセスするときの権限を、アプリごとに最小化したい。まず紐づけるべきKubernetesリソースはどれですか？

答え： ServiceAccount

PodにはServiceAccountを紐づけられます。実際の許可はRole/ClusterRoleとRoleBinding/ClusterRoleBindingで最小権限にします。

Namespace内のユーザーにPod一覧の参照だけを許可し、クラスタ全体の権限は与えたくない。使う組合せとして適切なのはどれですか？

答え： Role と RoleBinding

Namespace内だけの権限にはRoleを定義し、そのNamespaceでRoleBindingします。ClusterRoleBindingはクラスタ全体に広がるため過剰になりやすいです。

Podをrootユーザーで動かさない、特権コンテナを禁止するなど、Podのセキュリティ条件をNamespace単位で強めたい。代表的な仕組みはどれですか？

答え： Pod Security Admission

Pod Security AdmissionはNamespaceラベルでPod Security Standardsのレベルを適用し、Pod作成時にセキュリティ条件を検査できます。

アプリが永続ディスクを要求し、実際のストレージ実体とは疎結合にしたい。Pod側で参照する要求リソースはどれですか？

答え： PersistentVolumeClaim

PodはPVCを参照して必要な容量やアクセスモードを要求します。PVは実体、StorageClassは動的プロビジョニングの種類を表します。

クラウド環境でPVC作成時にストレージを自動作成し、SSDやHDDなどの種類を選ばせたい。主に使うリソースはどれですか？

答え： StorageClass

StorageClassは動的プロビジョニングで使うプロビジョナやパラメータを定義します。PVCから参照することでストレージを自動作成できます。

PodがPendingのまま起動しない。スケジューリング失敗やPVC未束縛などの理由をまず確認するコマンドはどれですか？

答え： kubectl describe pod <pod>

Pendingではコンテナがまだ動いていないことが多く、describeでEventsを確認するとスケジューリング失敗、リソース不足、PVC未束縛などを追えます。

PodがCrashLoopBackOffになっている。直前に終了したコンテナのログを確認したい。適切なオプションはどれですか？

答え： kubectl logs <pod> --previous

--previousを付けると、再起動前の終了済みコンテナインスタンスのログを取得できます。CrashLoopBackOffの原因調査で有効です。

クラスタ外からHTTPでアプリへアクセスさせ、ホスト名やパスごとに複数Serviceへ振り分けたい。主に定義するリソースはどれですか？

答え： Ingress

IngressはHTTP/HTTPSの入口ルールを定義し、ホスト名やパスに応じてServiceへルーティングします。実際の処理にはIngress Controllerが必要です。

Podが何度も再起動し、直前の終了理由がOOMKilledになっている。最初に見直す内容として最も適切なものはどれですか？

答え： 実際のメモリ使用量とmemory request/limitを確認し、アプリまたは制限値を調整する

OOMKilledはコンテナが利用可能なメモリを超えたことを示します。メトリクス、使用傾向、request/limit、メモリリークを確認し、根拠を持って調整します。

新しいPodがImagePullBackOffになった。まず確認する組合せとして最も適切なものはどれですか？

答え： PodのEvents、イメージ名・タグ、レジストリ認証用imagePullSecrets

ImagePullBackOffではdescribeでEventsを確認し、存在しないタグ、レジストリ到達性、認証Secretの設定などを切り分けます。

Deploymentの新バージョンでエラー率が急増したため、直前の正常なリビジョンへすぐ戻したい。適切なコマンドはどれですか？

答え： kubectl rollout undo deployment/<name>

rollout undoはDeploymentを以前のリビジョンへ戻します。実行後はrollout statusとアプリ指標で復旧を確認します。

起動に数分かかるアプリで、起動処理中にlivenessProbeが失敗して再起動を繰り返している。適切な改善はどれですか？

答え： startupProbeを設定し、成功するまでliveness/readinessの開始を待たせる

startupProbeは遅い初期化の完了を判定し、成功前のliveness/readiness実行を抑えます。起動後は通常の健全性確認を継続できます。

3つのAvailability Zoneにまたがるクラスタで、同じアプリのPodが1ゾーンへ偏るのを抑えたい。適切な設定はどれですか？

答え： topologySpreadConstraintsをzoneラベルに対して設定する

topologySpreadConstraintsはzoneなどのトポロジードメイン間で、条件に一致するPodの偏りを制御します。

ServiceのClusterIPへ接続できるが応答先がなく、EndpointSliceにエンドポイントが表示されない。最初に確認すべきものはどれですか？

答え： Serviceのselectorが対象Podのlabelsと一致しているか

selectorとPod labelが一致しないとServiceはバックエンドを選択できず、対応するEndpointSliceにPod IPが登録されません。

Podからapi.backend.svc.cluster.localの名前解決だけが失敗している。切り分けとして適切なものはどれですか？

答え： Pod内からnslookup等を実行し、Service名・NamespaceとCoreDNSの状態を確認する

クラスタDNSの問題は、呼び出し元Podでの名前解決結果、FQDNのService名とNamespace、CoreDNS Pod・ログ・Serviceを順に確認します。

稼働中アプリのPVC容量を増やしたい。事前条件として主に確認すべきものはどれですか？

答え： StorageClassがボリューム拡張を許可し、CSIドライバ等が拡張をサポートしていること

PVC拡張にはStorageClassのallowVolumeExpansionと、ストレージドライバ・基盤側の対応が必要です。ファイルシステム拡張の条件も確認します。

各レプリカに安定した名前と個別の永続ボリュームが必要なデータストアを運用したい。適切なworkloadはどれですか？

答え： StatefulSet

StatefulSetはPodへ安定した序数付きIDを与え、volumeClaimTemplatesで各レプリカ専用のPVCを管理できます。

一般的なLinuxコンテナで不要なシステムコールを既定プロファイルで制限したい。securityContextで指定するものはどれですか？

答え： seccompProfile.type: RuntimeDefault

RuntimeDefaultはコンテナランタイムの既定seccompプロファイルを使用してシステムコールを制限します。ワークロード互換性を検証して適用します。

CPU使用率を基準にしたHPAでTARGETSが<unknown>になり、レプリカ数が変化しない。最初に確認する組合せはどれですか？

答え： Metrics APIの提供状態と、対象コンテナのCPU requests

リソース使用率ベースのHPAにはMetrics APIからのメトリクスと、使用率計算の基準になるrequestsが必要です。HPAのdescribeイベントも併せて確認します。

5分ごとのCronJobで、前回の処理が終わっていない場合は新しいJobを開始させたくない。指定する設定はどれですか？

答え： concurrencyPolicy: Forbid

concurrencyPolicyをForbidにすると、前回実行が継続中のスケジュール時刻には新しいJobを開始しません。処理時間とスケジュール間隔も監視します。

JobのPodが失敗を繰り返すとき、一定回数でJobを失敗扱いにして無制限な再試行を避けたい。主に指定するものはどれですか？

答え： backoffLimit

JobのbackoffLimitは失敗時の再試行上限を制御します。処理自体の時間上限が必要ならactiveDeadlineSecondsも検討します。

ログ収集エージェントを対象となる各Nodeに1つずつ配置し、Node追加時にも自動配置したい。適切なworkloadはどれですか？

答え： DaemonSet

DaemonSetは条件に一致する各NodeへPodを配置するため、ログ・監視・ネットワークエージェントの常駐に適しています。

GPU Nodeにdedicated=gpu:NoScheduleというtaintがある。GPUワークロードだけを配置候補にするため最低限必要な設定はどれですか？

答え： 対応するtolerationをPodへ設定する

NoSchedule taintがあるNodeへ新規Podを配置するには一致するtolerationが必要です。ただしtolerationだけでは配置先をGPU Nodeに限定しないため、通常はnode affinity等も併用します。

特定のコンプライアンスラベルを持つNodeだけにPodを必ず配置したい。柔軟なラベル条件を表現できる設定はどれですか？

答え： requiredDuringSchedulingIgnoredDuringExecutionのnodeAffinity

requiredのnodeAffinityは、指定したNodeラベル条件を満たす場合だけスケジュールを許可します。IgnoredDuringExecutionなので配置後のラベル変更時に自動退避はしません。

クラスタ資源が不足した際、重要なシステムPodを低優先度Podより先にスケジュールしやすくしたい。使用する仕組みはどれですか？

答え： PriorityClassを作成してPodへpriorityClassNameを指定する

PriorityClassはPodのスケジューリング優先度を表します。設定によっては高優先度Podのために低優先度Podがpreemptionされるため、影響を評価して使います。

メインコンテナの起動前に、設定ファイル生成処理を正常完了させたい。失敗時はメインコンテナを開始させない構成はどれですか？

答え： init container

init containerはアプリコンテナより前に順番に実行され、すべて正常完了してからメインコンテナが開始します。共有Volumeで生成物を渡せます。

Namespace内で、requestsやlimitsを省略したコンテナへ既定値を設定し、個々のコンテナの最小・最大値も制約したい。使うリソースはどれですか？

答え： LimitRange

LimitRangeはNamespace内のPodやContainer等について既定request/limitや最小・最大値を定義します。Namespace全体の総量制限にはResourceQuotaを併用します。

PodをQoSクラスGuaranteedにしたい。CPUとメモリについて必要な設定はどれですか？

答え： 全コンテナでCPU・メモリのrequestsとlimitsを設定し、それぞれ同じ値にする

Guaranteedには全コンテナでCPUとメモリのrequest・limitが設定され、各リソースでrequestとlimitが等しいことが必要です。

コンテナが大量の一時ファイルを書き、Nodeのディスク圧迫で退避されるリスクを管理したい。設定・監視すべきリソースはどれですか？

答え： ephemeral-storageのrequestsとlimits

ローカル一時ストレージにはephemeral-storageのrequest/limitを設定できます。emptyDir、書き込み可能レイヤ、ログの使用量とNodeのDiskPressureも監視します。

Secretマニフェストのdataに値をbase64で記載した。セキュリティ上の説明として正しいものはどれですか？

答え： base64は符号化であり暗号化ではないため、RBACや保存時暗号化なども必要

base64は可逆な表現変換で機密性を提供しません。最小権限RBAC、etcdの保存時暗号化、外部Secret管理、リポジトリへの平文混入防止を組み合わせます。

あるユーザーへ全NamespaceのNode参照権限を付与したい。ClusterRoleは既にある。クラスタ全体へ紐づけるリソースはどれですか？

答え： ClusterRoleBinding

ClusterRoleBindingはClusterRoleの権限をクラスタスコープで主体へ付与します。NodeはクラスタスコープのリソースなのでNamespace内だけのRoleBindingでは要件を満たしません。

誰がKubernetes APIでSecretを参照・変更したかを事後調査できるようにしたい。主に有効化・収集するものはどれですか？

答え： API Serverの監査ログを適切なaudit policyで記録する

Kubernetes監査ログはAPI要求の主体、操作、対象、結果などを記録できます。Secretの値を不用意にログへ残さないようaudit policyと保管・アクセス制御を設計します。

StatefulSetの各Podへpod-0.service.namespace.svcのような安定したDNS名で直接到達したい。組み合わせるService設定はどれですか？

答え： clusterIP: Noneのheadless Service

StatefulSetをheadless Serviceと組み合わせると、安定したPod名に基づくDNSレコードを提供できます。単一の仮想IPで負荷分散する用途とは異なります。

egressをdefault-denyにしたNamespaceで、アプリから許可済み外部APIへFQDN相当の名前で接続させたい。見落としやすい追加許可はどれですか？

答え： クラスタDNSへのUDP/TCP 53番など、名前解決に必要なegress

egress default-denyでは外部API宛てだけでなく、名前解決に使うCoreDNS等への通信も明示許可が必要です。利用CNIのNetworkPolicy機能も確認します。

レプリカ3のDeployment更新中も利用可能Podを3未満にせず、一時的に1Podだけ追加作成を許可したい。設定はどれですか？

答え： maxUnavailable: 0、maxSurge: 1

maxUnavailable 0は更新中の利用可能数低下を許さず、maxSurge 1は希望レプリカ数を1つ超えるPodの一時作成を許可します。クラスタ余力も必要です。

Pod終了時に新規受付を止め、処理中リクエストを完了させてからプロセスを終了したい。主に組み合わせる設計はどれですか？

答え： SIGTERM処理、必要なpreStop、十分なterminationGracePeriodSeconds

Kubernetesは終了時に通常SIGTERMを送り、猶予期間後に強制終了します。アプリのSIGTERM処理、必要に応じたpreStop、処理時間を満たす猶予期間を設計します。

DeploymentのPodへ、ConfigMapの値を環境変数として渡しています。ConfigMapだけを更新しても稼働中の値が変わりません。反映方法として適切なのはどれですか？

答え： Podを順次作り直し、新しい環境変数で起動させる

環境変数はコンテナ起動時に設定されるため、ConfigMapの変更だけでは既存プロセスに反映されません。DeploymentのPodを順次置き換え、起動後の値を確認します。利用可能なPod数を保つ更新設定も必要です。

NetworkPolicyで、team=paymentsのNamespace内にあるapp=apiのPodを送信元として指定します。二つの条件を同時に満たす書き方はどれですか？

答え： fromの同じ要素にNamespace条件とPod条件を書く

同じfrom要素のnamespaceSelectorとpodSelectorは、両方を満たすPodを選びます。別要素に分けると許可範囲が合算されます。実際の通信では他のポリシー、送信側の制御、ネットワークプラグインも確認します。

PVCのアクセスモードをReadWriteOnceにしました。同じノード上の複数Podがこのボリュームへアクセスできる点について、正しい理解はどれですか？

答え： 単一ノードの読書きを表し、単一Podの制限とは異なる

ReadWriteOnceの単位はPodではなくノードです。同一ノード上の複数Podが利用できる場合があり、アプリの排他制御まで保証しません。単一Podに制限したい場合は、対応するCSI環境でReadWriteOncePodを検討します。

Deploymentの更新が止まり、ProgressDeadlineExceededになりました。外部の自動復旧ツールは使っていません。この状態の説明として正しいものはどれですか？

答え： 進行停止を報告する状態であり、自動で旧版へ戻るわけではない

progressDeadlineSecondsは進行が止まったことを検出するための設定です。状態を報告しますが、標準のDeployment制御だけで自動ロールバックは行いません。イベントやPodを調べ、修正または明示的な切り戻しを判断します。

Helmで-f base.yaml -f prod.yamlの順に指定しました。同じreplicaCountがbaseでは2、prodでは5です。他の上書き指定がない場合、値の扱いとして正しいものはどれですか？

答え： 後に指定したprodの5が採用される

複数の-fで同じキーを指定すると、後に指定したファイルの値が優先されます。この場合は5です。実際のリリースでは他の上書き指定も確認し、テンプレートの展開結果で意図した値になっているかを確かめます。

Helm Chartのcrds/にあるCRDを変更しました。CRDは独自リソースの型を定義するものです。既存リリースへの通常のhelm upgradeだけで更新されるか、正しい理解はどれですか？

答え： 既存CRDは自動更新されず、別途変更手順を用意する

crds/のCRDは、通常のHelmテンプレートと同じ更新管理にはなりません。既存CRDの変更は、独自リソースとの互換性や保存データへの影響を確認して別途管理します。安易な削除と再作成はデータ損失につながり得ます。

Deploymentをapp:v1で作成し、imagePullPolicyは省略しました。その後、imageだけをapp:latestに変更します。取得方針を変える仕組みがほかにない場合、正しい説明はどれですか？

答え： 保存済みの取得方針は残るため、必要なら明示的に変える

作成時に既定値として入ったIfNotPresentは、タグを変更しただけではAlwaysへ変わりません。必要な取得方針を明示します。Alwaysでも同じダイジェストのイメージがあれば再利用でき、毎回全データを取り直すという意味ではありません。

ServiceAccountでautomountServiceAccountTokenをfalseにしました。しかしPod側ではtrueを指定しています。ほかの変更機構がない場合、自動マウントの判定として正しいものはどれですか？

答え： Pod側のtrueが優先され、自動マウントが有効になる

両方に指定があるときはPod側が優先されます。APIを利用しないアプリで自動マウントを止めたい場合、Podの指定も確認します。これはトークンの自動配置を制御する設定であり、RBAC権限の取消とは別です。

独自リソースを削除しましたが、外部資源を片付けるfinalizerが残り、削除待ちになっています。対応の第一歩として適切なのはどれですか？

答え： 担当コントローラと後処理の失敗原因を調べ、解消する

finalizerは、必要な後処理が終わる前にリソースが消えないようにする仕組みです。担当コントローラの停止や外部APIの失敗を調べます。手動で外すのは、目的と影響を理解し、必要な後処理を別途完了した場合に慎重に判断します。

Jobをparallelism=1、completions=1、restartPolicy=Neverで動かします。外部APIへの同じ登録を重複させたくない場合、アプリ設計として適切なのはどれですか？

答え： 再実行を想定し、同じ処理IDで重複登録を防ぐ

この設定でも同じプログラムが再び起動する場合があります。Jobの完了数は外部APIの副作用を一度だけにする保証ではありません。APIが対応する冪等キーや一意制約などを使い、応答が失われても同じ処理を識別できるようにします。