Configuration Quiz
このクイズでは、ConfigMap、Secret、環境変数、resource requests と limits を含む Kubernetes の設定概念についての理解を確認します。
Multiple Choice Questions
- Kubernetes で機密情報を保存するために使用される resource は何ですか?
- A) ConfigMap
- B) Secret
- C) Volume
- D) Deployment
回答を表示
回答: B) Secret
解説: Secret は、password、OAuth token、SSH key などの機密情報を保存するための Kubernetes resource です。Secret はデフォルトで base64 にエンコードされて保存され、ファイルまたは環境変数として Pod にマウントできます。ConfigMap は機密性のない設定データを保存するために使用されます。
- Kubernetes における ConfigMap の主な目的は何ですか?
- A) container image を保存する
- B) アプリケーション設定データを保存する
- C) network policy を定義する
- D) Pod のスケジューリングを制御する
回答を表示
回答: B) アプリケーション設定データを保存する
解説: ConfigMap は、key-value pair で設定データを保存する Kubernetes resource です。これにより、アプリケーションコードと設定を分離でき、環境ごとに異なる設定を使用できます。ConfigMap は、環境変数、command-line arguments、または設定ファイルとして container にマウントできます。
- Kubernetes Pod における resource requests と limits の違いは何ですか?
- A) requests は Pod が使用できる最小 resource、limits は最大 resource
- B) requests は Pod が使用できる最大 resource、limits は最小 resource
- C) requests はスケジューリングにのみ使用され、limits は runtime にのみ適用される
- D) requests は CPU にのみ適用され、limits は memory にのみ適用される
回答を表示
回答: A) requests は Pod が使用できる最小 resource、limits は最大 resource
解説: Resource requests は Pod に保証される resource の最小量を指定し、scheduler は Pod を Node に配置するときにこれらの値を使用します。Resource limits は Pod が使用できる resource の最大量を指定します。これらの値を超えると、Pod は (CPU の場合) throttled されたり、(memory の場合) terminated されたりする可能性があります。
- Kubernetes で Secret data を Pod に提供する方法ではないものはどれですか?
- A) 環境変数として
- B) マウントされた volume として
- C) image registry credentials として
- D) network interface として
回答を表示
回答: D) network interface として
解説: Kubernetes で Secret data を Pod に提供する方法には、環境変数として、マウントされた volume として、image registry credentials として提供する方法があります。network interface を通じて Secret を提供することは Kubernetes ではサポートされていません。
- Kubernetes で ConfigMap を作成する方法ではないものはどれですか?
- A) literal value から
- B) ファイルから
- C) ディレクトリから
- D) network request から
回答を表示
回答: D) network request から
解説: Kubernetes で ConfigMap を作成する方法には、literal value (--from-literal) から、ファイル (--from-file) から、ディレクトリ (--from-file=<directory>) から作成する方法があります。network request から直接 ConfigMap を作成することは、Kubernetes ではネイティブにはサポートされていません。
- Kubernetes で Pod の service account を指定するために使用される field は何ですか?
- A) spec.serviceAccount
- B) spec.serviceAccountName
- C) metadata.serviceAccount
- D) spec.account
回答を表示
回答: B) spec.serviceAccountName
解説: Kubernetes では、Pod の service account は spec.serviceAccountName field を通じて指定されます。この field により、Pod が使用する service account を指定できます。指定しない場合、namespace の default service account が使用されます。
- Kubernetes における Secret data のデフォルトのエンコード方式は何ですか?
- A) AES-256
- B) Base64
- C) SHA-256
- D) エンコードなし
回答を表示
回答: B) Base64
解説: Kubernetes の Secret data はデフォルトで Base64 にエンコードされて保存されます。これは単なるエンコードであり、暗号化ではないため、追加のセキュリティ対策が必要です。Kubernetes 1.13 以降、etcd に保存される Secret data の暗号化が利用可能です。
- Kubernetes で環境変数を設定する方法として、最も推奨されないものはどれですか?
- A) ConfigMap から
- B) Secret から
- C) Pod spec に直接ハードコードする
- D) Downward API から
回答を表示
回答: C) Pod spec に直接ハードコードする
解説: 環境変数を Pod spec に直接ハードコードすることは、設定とコードを分離する原則に反するため推奨されません。ConfigMap または Secret を使用して環境変数を管理すると、アプリケーションコードを変更せずに設定を変更できます。また Downward API を使用すると、Pod metadata や resource 情報を環境変数として提供できます。
- Pod 内のすべての container に resource requests と limits が設定され、requests が limits と等しい場合、どの QoS (Quality of Service) class が割り当てられますか?
- A) Guaranteed
- B) Burstable
- C) BestEffort
- D) Critical
回答を表示
回答: A) Guaranteed
解説: Guaranteed QoS class は、Pod 内のすべての container に resource requests と limits が設定され、requests が limits と等しい場合に割り当てられます。この class の Pod は、resource が不足しているときに最後に termination されます。Burstable は、一部の container のみに requests と limits が設定されている場合、または requests と limits が異なる場合に割り当てられます。BestEffort は、requests または limits が設定されていない場合に割り当てられます。
- ConfigMap または Secret への変更が Pod に自動的に反映されるのはいつですか?
- A) 常に自動的に反映される
- B) volume としてマウントされた場合のみ
- C) 環境変数として使用された場合のみ
- D) 自動的には反映されない。Pod の restart が必要
回答を表示
回答: B) volume としてマウントされた場合のみ
解説: ConfigMap または Secret が volume としてマウントされている場合、Kubernetes はマウントされたファイルを定期的に更新します (デフォルトは約 1 分です)。ただし、環境変数として使用される場合は、Pod の作成時に一度だけ設定されるため、変更を反映するには Pod を restart する必要があります。これは、環境変数が process startup 時に設定されるためです。
Hands-on Questions
- ConfigMap と Secret を作成し、それらを環境変数および volume として Pod にマウントする方法を説明してください。
回答を表示
回答:
- ConfigMap を作成する:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
app.properties: |
app.name=MyApp
app.version=1.0.0
database.properties: |
db.host=mysql
db.port=3306
db.name=mydb- Secret を作成する:
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
db.user: YWRtaW4= # admin (base64 encoded)
db.password: cGFzc3dvcmQxMjM= # password123 (base64 encoded)- 環境変数および volume としてマウントする Pod を作成する:
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: myapp:1.0
env:
# Get environment variable from ConfigMap
- name: APP_NAME
valueFrom:
configMapKeyRef:
name: app-config
key: app.properties
subPath: app.name
# Get environment variables from Secret
- name: DB_USER
valueFrom:
secretKeyRef:
name: app-secrets
key: db.user
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: app-secrets
key: db.password
volumeMounts:
# Mount ConfigMap as volume
- name: config-volume
mountPath: /etc/config
# Mount Secret as volume
- name: secret-volume
mountPath: /etc/secrets
readOnly: true
volumes:
# Define ConfigMap volume
- name: config-volume
configMap:
name: app-config
# Define Secret volume
- name: secret-volume
secret:
secretName: app-secrets- resource を適用する:
kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl apply -f pod.yaml- 環境変数を確認する:
kubectl exec app-pod -- env | grep -E 'APP_NAME|DB_'- マウントされた volume を確認する:
kubectl exec app-pod -- ls -la /etc/config
kubectl exec app-pod -- ls -la /etc/secrets- ファイル内容を確認する:
kubectl exec app-pod -- cat /etc/config/app.properties
kubectl exec app-pod -- cat /etc/secrets/db.user- Pod に resource requests と limits を設定し、QoS class を確認する方法を説明してください。
回答を表示
回答:
- 異なる QoS class の Pod を作成する:
Guaranteed QoS Pod:
apiVersion: v1
kind: Pod
metadata:
name: guaranteed-pod
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "100Mi"
cpu: "100m"
limits:
memory: "100Mi"
cpu: "100m"Burstable QoS Pod:
apiVersion: v1
kind: Pod
metadata:
name: burstable-pod
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "100Mi"
cpu: "100m"
limits:
memory: "200Mi"
cpu: "200m"BestEffort QoS Pod:
apiVersion: v1
kind: Pod
metadata:
name: besteffort-pod
spec:
containers:
- name: nginx
image: nginx
# No resource requests or limits- Pod を作成する:
kubectl apply -f guaranteed-pod.yaml
kubectl apply -f burstable-pod.yaml
kubectl apply -f besteffort-pod.yaml- QoS class を確認する:
kubectl get pods guaranteed-pod -o jsonpath='{.status.qosClass}'
# Output: Guaranteed
kubectl get pods burstable-pod -o jsonpath='{.status.qosClass}'
# Output: Burstable
kubectl get pods besteffort-pod -o jsonpath='{.status.qosClass}'
# Output: BestEffort- Pod の詳細を確認する:
kubectl describe pod guaranteed-pod | grep QoS
kubectl describe pod burstable-pod | grep QoS
kubectl describe pod besteffort-pod | grep QoS- resource 使用量を監視する:
kubectl top pod guaranteed-pod
kubectl top pod burstable-pod
kubectl top pod besteffort-podQoS Class Decision Rules:
- Guaranteed: すべての container に resource requests と limits が設定され、requests が limits と等しい
- Burstable: 少なくとも 1 つの container に resource requests が設定されているが、Guaranteed の条件を満たしていない
- BestEffort: どの container にも resource requests または limits が設定されていない
- Downward API を使用して Pod metadata と resource 情報を container に提供する方法を説明してください。
回答を表示
回答:
- Downward API を使用する Pod を作成する:
apiVersion: v1
kind: Pod
metadata:
name: downward-api-pod
labels:
app: myapp
environment: production
spec:
containers:
- name: main
image: busybox
command: ["sh", "-c", "while true; do echo Downward API Demo; sleep 10; done"]
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
env:
# Provide pod metadata as environment variables
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
- name: POD_LABEL_APP
valueFrom:
fieldRef:
fieldPath: metadata.labels['app']
# Provide container resource information as environment variables
- name: CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: main
resource: requests.cpu
- name: CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: main
resource: limits.cpu
- name: MEM_REQUEST
valueFrom:
resourceFieldRef:
containerName: main
resource: requests.memory
divisor: "1Mi"
- name: MEM_LIMIT
valueFrom:
resourceFieldRef:
containerName: main
resource: limits.memory
divisor: "1Mi"
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
# Provide Downward API as volume
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
- path: "cpu-request"
resourceFieldRef:
containerName: main
resource: requests.cpu
- path: "cpu-limit"
resourceFieldRef:
containerName: main
resource: limits.cpu- Pod を作成する:
kubectl apply -f downward-api-pod.yaml- 環境変数を確認する:
kubectl exec downward-api-pod -- env | sort- volume ファイルを確認する:
kubectl exec downward-api-pod -- ls -la /etc/podinfo
kubectl exec downward-api-pod -- cat /etc/podinfo/labels
kubectl exec downward-api-pod -- cat /etc/podinfo/cpu-requestFields Available via Downward API:
Fields available as environment variables:
metadata.name- Pod 名metadata.namespace- Pod namespacemetadata.uid- Pod UIDmetadata.labels['<KEY>']- Pod label valuemetadata.annotations['<KEY>']- Pod annotation valuestatus.podIP- Pod IP addressspec.nodeName- Pod が実行されている Node の名前spec.serviceAccountName- Pod の service account 名status.hostIP- Pod が実行されている Node の IP address
Resource fields:
requests.cpu- CPU requestlimits.cpu- CPU limitrequests.memory- Memory requestlimits.memory- Memory limit