Open2022/09/09にコメント追加27

Kubernetesについて色々学ぶ

Service

＊kubectl expose deployment go-app --type=LoadBalancer --port 80 --target-port 8080とするとselectorがapp=go-appとなる。selectorがないとバックエンドに通信できなくなる。

セレクターなしのService

このServiceはセレクターがないため、対応するEndpointsオブジェクトは自動的に作成されません。ユーザーはEndpointsオブジェクトを手動で追加することにより、向き先のネットワークアドレスとポートを手動でマッピングできます。

種類

type=ClusterIPの場合はServiceをKubernetesクラスター内部のIPで公開します。
このタイプではServiceはクラスター内部からのみアクセスでき、外部からのアクセスはできません。
type=NodePortの場合は、各Node VMのIPを使ってServiceを公開します。
Node VMのIPを使うので、クラスター内部からだけでなくそのVMにアクセスできる外部のアプリからもアクセスすることができます。

LabelとSelector

LabelとSelectorを設定することで通信したい相手を選択できる。

Labelを外す

＊誤ってArgoCDの管理下に置いてしまったとき

kubectl label ns default argocd.argoproj.io/instance-

Namespace

Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。

デフォルトではクラスタ内であればnamespace越しの通信が許可されています。もし、これを許容できない要件があれば、NetworkPolicyを利用することで制限できます。ただし、NetworkPolicyが利用できるのはコンピューティングタイプがEC2の場合のみで、Fargateを利用する場合はこれを利用できません。

StatefulSet

StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの順序と一意性を保証します。

カスタムリソース

カスタムリソースはKubernetes APIの拡張です

CustomResourceDefinition(CRD)

ConfigMap

設定情報などのデータを、Key-Value形式で保存しておくリソース。
言い換えると、環境変数を登録しておけるリソース。

HPA

Kubernetesでは、HorizontalPodAutoscalerがワークロードリソース、需要に合わせてワークロードを自動的にスケーリングすることを目的としています。

Prometheusなどと連携して、カスタムメトリクス(custom.metrics.k8s.io)APIを使ってオートスケールすることもできる。

Job

Jobとは、1つ以上のPodを作成し、指定された数のPodの処理が成功するまで動き続けるオブジェクトです。

CronJob

CronJobとは、スケジュールに基づきJobを作成するオブジェクトです。

restartPolicy: Never
Job失敗時は指定した回数分新規のPodが起動され、リトライを繰り返す。

restartPolicy: OnFailure
Job失敗時は指定した回数分同一のPodでリトライを繰り返す。

Alwaysであれば、kubeletは「podが常に動き続けている状態」を保証しようと振る舞うので、Deployment

OnFailureであれば、kubeletは「podに障害が発生した時や障害が発生した時に新しいpodを開始させる」ように振る舞うので、Job

Neverであれば、特にrestartする必要がないので通常のpodとなる

User Account

外部からユーザーが Kubernetes を操作するために使うユーザーアカウントです。ユーザーアカウントの認証はローカルに置かれている ~/.kube/config にある kubeconfig ファイルの中にあるクライアント証明書というものを用いて行います。

Service Account

K8s のリソースで、API サーバーにリクエストを出す時の認証/認可で使用される。Pod で直接 K8s のリソースを操作する時などに使用する
Podと紐づけることでPodからKubernetesAPIを操作できるようになります。Namespaceに紐づくリソースには全てServiceAccountが紐づきます。

＊ServiceAccountはそれだけではリソースに対する操作を行う権限を持ちません。RBACではどんなユーザー(ServiceAccount)か、ではなくユーザーがどんなロールを持っているかで権限が決まります。kubernetesにはロールに関わるリソースは Role・ClusterRole・RoleBinding・ClusterRoleBinding
の４つがあります。

https://knowledge.sakura.ad.jp/21129/

Role・ClusterRole

RoleとClusterRoleの違いはNamespaceで分離されているかどうか。 RoleはNamespaceで分離されている。 ClusterRoleはNamespaceで分離されておらず、クラスター全体から参照できる。
権限は追加方式であり、拒否する権限はありません

RoleBinding・ClusterRoleBinding

RoleBindingとClusterRoleBindingはどのRole/ClusterRoleをどのServiceAcctountに紐付ける。

aws-auth, irsa

port-forward

Deployment・Serviceに紐づくPodへのポートフォワーディング。もちろん特定のPodを指定して行うことも可能。

kubectl port-forward deployment/sample-deployment 8888:80

Limit Request

Requestsは使用するリソースの下限を指定します。Limitsは使用するリソースの上限を指定します。

containers:
- name: nginx
  image: nginx:1.16
  resources:
    requests:
      cpu: "350m"
    limits:
      cpu: "600m"

NetworkPolicy

Podに対して、Pod間の通信や外部のエンドポイントへの通信を制御する為のリソース

ExternalName

セレクターなしのServiceへのアクセスは、セレクターをもっているServiceと同じようにふるまいます。上記の例では、トラフィックはYAMLファイル内で192.0.2.42:9376 (TCP)で定義された単一のエンドポイントにルーティングされます。

ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介するExternalNameを参照ください。

＊Namespace間通信

アノテーション

kubectlプロキシを使用する

以下でkubernetes APIにリクエストできるようになる。

kubectl proxy --port=8080

curl http://localhost:8080/api/

GET /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}

ステートフル　ステートレス

Pod

PodのStatus・・・Pending, Running, Succeeded, Failed, Unknownのはずだが、Status Errorの時もあった。その時はargsに誤ったものを指定していた。

restartPolicy

Probe

Liveness Probe

コンテナが生きているか確認する。コマンド, HTTP, TCPの３つの確認の仕方がある。

Readiness Probe

コンテナがトラフィックを受け入れられる状態であるか判断してくれる。HTTPとTCPの確認法。

Startup Probe

コンテナの起動のタイムアウトとして使える。300秒経過すると終了し、その後はPodのrestartPolicyに従う。

Probeの動き

Probeが失敗した時のみPodにエラーが出る。
エラーが出た場合 30 × 10
failureThreshold: 30periodSeconds: 10

 Startup Probe(タイムアウト) →
成功→ Liveness Probe(コンテナのヘルスチェック)
失敗→ restartPolicy

PodDisruptionBudget

Node が排出されるときに削除される Pod の数を制限する設定

Fargate

hostPort: 8080はできない

ネットワーク応用

kubernetesのネットワーク
custom controller