CKA対策vol.2

CKA対策vol.2です。

vol.1はこちら

podに作成済みのpersistentVolume(pv)をマウントする

まずはk describe pv <pvName>で当該pvの詳細を確認。

例：

kubectl describe pv task-pv-volume
Name:            task-pv-volume
Labels:          type=local
Annotations:     <none>
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Terminating
Claim:
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        1Gi
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/data
    HostPathType:
Events:            <none>

persistetntVolumeClaim(pvc)を作成し、pvをpvcにマウントする。この時、accessModeとstorageのサイズを一致させるのがポイント。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

podを作成する。ポイントは2つ。

• spec.containers.volumeMounts.nameとspec.volumes.nameを一致させる。
• spec.volumes.persostentVolumeClaim.claimNameは、使用したいpvcのmetadata.nameと一致させる。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Role-Based Access Control(RBAC)を使用して権限を管理する

※ちょっとここ理解が曖昧で用語を間違って使っているかもしれません。ご注意ください。

ユーザーを作成する。
csrを適用し、approveされることでユーザーができる。

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: <keyEncodedByBase64>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth

以下手順

• cat <keyfile> | base64 | tr -d "\n"でエンコードし、それを`に張り付ける。
• k create -f でcsrを作成する。
• k get csrで確認するとconditionがpendingとなっている。これをkubectl certificate approve <name>することで要求が承認される。

続いてroleを作成する。マニフェストファイルをapplyするDeclarative (宣言的)な方法で進めたかったがわからなかったので、コマンドベースで作成するImperative (命令的) な方法で進める。

以下手順

• (k create role —helpでcreate roleの使い方を検索する)
• Eampleに kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=podsと出てくるのでコピペし、目的に合うように修正。nsも指定する必要がある。
• (k create rolebinding —helpでcreate rolebindingの使い方を検索する)
• Exampleにk create rolebinding admin --clusterrole=admin --user=user1と出てくるのでコピペし、目的に合う用に修正。nsも指定する必要がある。
• k auth can-i get pods -n <ns> —as <userName>で権限を確認する。OKがでればget podsができているということになる。

クラスター内部からpodとimageに対してアクセスできるかどうかをnslookupを使って確認する

以下手順

• podを作成する。serviceでselectorを利用するので、ラベルを付けておく。(今回はapp: MyAppというラベルを付与する。)

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    app: MyApp
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

• serviceを作成する。このとき、typeはClusterIPにし、portとtargetPortの設定をしておく。(デフォルトのtypeはClusterIPなので、特に記述は必要ない。)

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

• 確認用のpodを立て、nslookupする。kubectl run <podName> --image=<image> -it -- nslookup <argument>
• URL?(nslookupの後ろに指定する引数)に関して
  • serviceの場合はservice名にする。
  • podの場合は<ハイフンで区切られたIP>.<namespace>.<pod>.<cluster名>とする。
    • cluster名はデフォルトではcluster.localとなっている。
    • /etc/kubernetes/manifests/kube-apiserver.yamlを確認して調べることも可能。