12,673
回編集
差分
ナビゲーションに移動
検索に移動
==| [[Docker]] | [[KubernetesDocker コマンド]]==| [[Dockerネットワーク]] | [[WSL]] | [[MicroK8s]] | [[Multipass]] | ==[https://kubernetes.io/ja/ Kubernetes]==
====Workloadsリソース====
====Discovery ＆ LBリソース====
**{| class="wikitable"|-! scope="col"| Service! 内容|-| ClusterIP**| |-| ExternalIP （ClusterIPの一種)**| |-| NodePort**| |-| LoadBalancer**| |-| Headless （None)**| |-| ExternalName**| |-| None-Selector| |-|}
====Config & Storage リソース====
====Cluster リソース====
====Metadataリソース====
$ curl apiVersion: v1kind: Podmetadata: name: sample-podspec: containers: - name: nginx-Lo minikube httpscontainer image:nginx:1.12<//storagepre>====実行====*apply コマンドを利用すると、存在しなければ生成、更新があれば更新、変更なければ何もしないという挙動<pre>$ kubectl create -f sample-pod.googleapis.comyaml pod/minikubesample-pod created</releases/latest/minikube-linux-amd64pre>*確認<pre>$ sudo +x minkubekubectl get podNAME READY STATUS RESTARTS AGEsample-pod 1/1 Running 0 42s
====インストール====
====停止====*表示の拡張 > <pre>$ kubectl get pod --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-pod 1/1 Running 2 24h 172.17.0.3 minikube stop <none> <none>====クラスタを削除====</pre> > minikube delete*ダッシュボードに表示された[[File:Kubernetes_label.png|600px]]
$ kubectl create deployment helloapiVersion: apps/v1kind: Deploymentmetadata: name: sample-deployspec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-minikube app spec: containers: -name: nginx-container image=k8s: nginx:1.gcr.io19 ports: - containerPort: 80</echoserver:1pre>*作成<pre>$ kubectl apply -f sample-deploy.10yaml deployment.apps/hellosample-minikube rs created
[[File:K8s_deploy.png | 400px]]
===Deploymentに接続するために、Serviceとして公開===*確認(Pod)
[[File:K8s_service.png | 400px]]===Podが起動しているか確認===*作成
===公開サービスのURLを確認===*確認
[[File:K8s_service_run.png | 400px]]
$ kubectl versionapiVersion: apps/v1Client Versionkind: version.Info{MajorStatefulSetmetadata:"1", Minor name:"18", GitVersionwebspec:"v1.18.8", GitCommit selector:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState matchLabels:"clean", BuildDate app:"2020sample-08app serviceName: sample-13T16stateful replicas:123 template:48Z", GoVersion metadata:"go1.13.15", Compiler labels: app: sample-app spec:"gc", Platform terminationGracePeriodSeconds:"linux/amd64"}10Server Version containers: version.Info{Major - name:"1", Minornginx image:"18", GitVersionnginx:"v11.18.3", GitCommit19 ports:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState - containerPort:"clean", BuildDate80 name:"2020web volumeMounts: -05name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: -20T12metadata:43 name:34Z", GoVersionwww spec: accessModes:"go1.13.9", Compiler - ReadWriteOnce resources: requests:"gc", Platform storage:"linux/amd64"}1G
====ワーカーノードの表示====*クラスタ上の全のノードを表示確認
====ノードの詳細情報====<pre>*$ kubectl describe nodes [ノード名]get pvNo resources found in default namespace.</pre>
clusterskind:PersistentVolumeClaim- clustermetadata: certificate name: sample-authority: /home/piroto/.minikube/ca.crtpvc serverspec: https://192.168.39.214:8443 namestorageClassName: minikubemanualcontexts accessModes: - contextReadWriteOnce resources: clusterrequests: minikube user storage: minikube1Gi</pre> name: minikube*生成<pre>current$ kubectl apply -context: minikubef sample-pvc.yaml persistentvolumeclaim/sample-pvc createdkind: Config</pre>preferences: {}*確認users:<pre>$ kubectl get pvc -- name: minikubeoutput wideNAME STATUS VOLUME CAPACITY user:ACCESS MODES STORAGECLASS AGE VOLUMEMODE clientsample-certificate: /home/piroto/.minikube/profiles/minikube/client.crtpvc Bound clientsample-key: /home/piroto/.minikube/profiles/minikube/client.keypv 1Gi RWO manual 52s Filesystem
===Namespace===
*クラスタ内のオブジェクトを構造化
*kubectlはデフォルトではdefaultというNamespaceとやり取り
*--namespace で指定できる
===Context===
*デフォルトのNamespaceを恒久的に変更したい場合
*$HOME/.kube/config に保存される
===[[Kubernetes]] APIオブジェクトの参照===
*[[Kubernetes]]上にあるものは、すべてRESTFulリソースであらわされる
==Pod==
*同じ実行環境上で動くアプリケーションコンテナとストレージボリュームの集まりのこと
*Kubernetesクラスタ上では、コンテナではなくPodがデプロイの最小単位
*1つのPodないのコンテナは全て同じマシン上に配置される
*同じPod内のアプリケーションは、ネイティブなプロセス間通信チャネルで通信できるが、異なるPodのアプリケーションからは分離されている
===Pod単位で考える===
*WordPressとMySQLを同じPodに入れれば良いと考えるのはアンチパターンの1つ
*それぞれ別マシンで通信できればよく、WordPressとDBが同じ単位としてスケールする可能性も低い
*WordPress自体はステートレスなため、負荷が増大した場合、WordPressのPodを増やしてスケールさせれば良い
*通常は、Podを作る際に、コンテナが異なるマシンに配置されても正常に動作するかという点が判断基準
→Kubelet=
{{amazon|4873118409}}
{{amazon|B07HFS7TDT}}
*https://kubernetes.io/ja/
*コンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するプラットフォーム（コンテナオーケストレーションエンジン)
*https://knowledge.sakura.ad.jp/20955/
**Microsoft:Azure Container Ser[[vi]]ce
**Google:Google [[Kubernetes]] Engine
===[https://kubernetes.io/ja/docs/reference/kubectl/cheatsheet/ チートシート]===
*[https://kubernetes.io/ja/docs/reference/kubectl/cheatsheet/ チートシート]
===コンポーネント構成===
*https://kubernetes.io/docs/concepts/overview/components/
*https://www.slideshare.net/yokawasa/istio-114360124 から引用
[[File:kubernetes_component.png|600px]]
===宣言的なコードによる管理===
*kubectlは、マニフェストファイルの情報を元にKubernetes MasterのAPIにリクエストを送り、Kubernetesの操作を行う
*Kubernetes の API は一般的な RESTful API として実装されている
==構成=====クラスタ===*Kubernetesクラスターは以下の2種類のリソースで構成**マスターがクラスターを管理する、マスターはクラスターの管理を担当**ノードがアプリケーションを動かすワーカーとなる、ノードは、Kubernetesクラスターのワーカーマシンとして機能するVMまたは物理マシン====Kubelet====*各ノードにはKubeletがあり、これはノードを管理し、Kubernetesマスターと通信するためのエージェント ====デプロイ====Kubernetesにアプリケーションをデプロイするときは、#マスターにアプリケーションコンテナを起動するように指示#マスターはコンテナがクラスターのノードで実行されるようにスケジュール#ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信##エンドユーザーは、Kubernetes APIを直接使用して対話することもできます ====Kubernetes とリソース====
*Kubernetesでは、リソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる
*クラスタ上にコンテナを起動するために利用する
*内部的に利用されているものをのぞき、直接操作するものとしては、以下のリソースがある
**Job
**CronJob
===Pod===
*Workloadsリソースの最小単位
*一つ以上のコンテナから構成され、ネットワーク的に隔離されておらず、IPアドレスを共有する
*2つのコンテナが入ったPoｄを作成した場合、同一IPアドレスを持ち、お互い、localhostで通信できる
*多くの場合は、1つのPodに1つのコンテナを含めるが、補助するサブコンテナを複数含めることもある
*コンテナサービスディスカバリやクラスタの外部からもアクセス可能なエンドポイントなどを提供する
*利用者が直接利用するものとしては、Service と Ingress があり、Serviceは複数タイプが用意されている
*Service
*Ingress
===KubernetesクラスタのネットワークとService===
====Kubernetesが構成するネットワーク====
*Pod内には複数のコンテナを内包できるが、同じPodであれば、同一IPが割り振られている
*同一Podコンテナへ通信を行う場合は、localhostあてに通信を行い、Podのコンテナから別Podコンテナへ通信を行う場合には、PodのIPアドレス宛に通信を行う
*Kubernetesクラスタは、クラスタを構成するとノードにPodのための内部ネットワークを自動的に構成する
*基本的にはノードごとに異なるネットワークセグメントを互いに通信できるよう構成する
*このような内部ネットワークが自動構成されるため、PodはServiceを利用しなくてもPod間通信を行うことが可能
====Serviceを利用することによるメリット====
*Podあてトラフィックのロードバランシング
*サービスディスカバリとクラスタ内DNS
*これらは、上記のどのService Typeからも利用できる
====Pod宛トラフィックのロードバランシング====
*Serviceは、複数のPodにロードバランシングを行う
*Serviceを利用すると、各PodのIPを毎回調べたり、宛先を設定するなど独自に実現しなくても、自動的に構成することができる
*Serviceは、ロードバランシングのエンドポイントも提供する
**外部ロードバランサーが払い出す仮想IP（Virtual IPアドレス)、クラスタ内のみで利用可能な仮想IPアドレス(ClusterIP)など
*設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供する
*Secret と ConfigMap は Key-Value のデータ構造を持ち保存データが機密か一般化によって使い分ける
*PersistentVolumeClaim
*クラスタ自体の振る舞いを定義
*Node
*NetworkPolicy
*クラスタ内の他のリソースの動作を制御する
*LimitRange
*PodDisruptionBudget
*CustomResourceDefinition
==[[Minikube]]==
*[[Minikube]]
==minikube[[MicroK8s]]==*https://github.com/kubernetes/minikube*ローカル開発や学習、テスト用のシンプルな[[KubernetesMicroK8s]]シュミレータ*シングルノードクラスタで、インストールには、ローカルマシンにハイパーバイザーがインストールされていること*VT-x/AMD-v ==[[仮想化Kubectl]]がBIOSで有効化されていること。==*[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/ Minikubeを使用してローカル環境でKubernetesを動かす[Kubectl]]===インストール===*https://kubernetes.io/docs/tasks/tools/install-minikube/
==[https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces/ Namespace]==Ubuntu + 仮想環境*Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 この仮想クラスターをNamespaceと呼びます*作成:kubectl create namespace <名称>*削除:kubectl delete namespace <名称><pre>$ kubectl create namespace samplenamespace/sample created$ kubectl get namespacesNAME STATUS AGEkube-system Active 66dkube-public Active 66dkube-node-lease Active 66ddefault Active 66dsample Active 4s</pre> ==[https://kubernetes.io/ja/docs/concepts/workloads/pods/ Pod]==*[https://www.typeakubernetes.infoio/blogja/index.phpdocs/2020concepts/08workloads/22pods/ubuntu-kvm-bridge-network/ Ubuntu 仮想環境(KVM)構築]*同じ実行環境上で動くアプリケーションコンテナとストレージボリュームの集まりのこと*Kubernetesクラスタ上では、コンテナではなくPodがデプロイの最小単位*1つのPodないのコンテナは全て同じマシン上に配置される*同じPod内のアプリケーションは、ネイティブなプロセス間通信チャネルで通信できるが、異なるPodのアプリケーションからは分離されている===Pod単位で考える===*WordPressとMySQLを同じPodに入れれば良いと考えるのはアンチパターンの1つ*それぞれ別マシンで通信できればよく、WordPressとDBが同じ単位としてスケールする可能性も低い*WordPress自体はステートレスなため、負荷が増大した場合、WordPressのPodを増やしてスケールさせれば良い*通常は、Podを作る際に、コンテナが異なるマシンに配置されても正常に動作するかという点が判断基準
===設定=入手==*設定を行う箇所は、clusters,contexts,users*[[YAML]] もしくは JSONフォーマット*直接編集するだけでなく、kubectlから変更も可能*https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#pod-v1-core<pre>apiVersion: v1clusters:- cluster: certificate-authority: /home/piroto/.minikube/ca.crt server: https://192.168.39.214:8443 name: minikubecontexts:- context: cluster: minikube user: minikube name: minikubecurrent-context: minikubekind: Configpreferences: {}users:- name: minikube user: client-certificate: /home/piroto/.minikube/profiles/minikube/client.crt client-key: /home/piroto/.minikube/profiles/minikube/client.key</pre>===マニフェストとリソースの作成===*sample-pod.yaml
<pre>
</pre>
<pre>
$ sudo install minikube kubectl apply -f sample-pod.yaml pod/usr/local/binsample-pod configured
</pre>
===利用アノテーションとラベル===*各リソースに対してアノテーションとラベルというメタデータを付与することができる{| class====ローカルクラスタの作成===="wikitable"!名称!概要|-|アノテーション|システムコンポーネントが使用するメタデータ.アノテーションを元に処理するシステムコンポーネントが存在しない場合は単なるメモ|-|ラベル|リソース管理に利用するメターデータ.リソースを分別するための情報*ローカル仮想マシンを作成|}*[[Kubernetes]]を設定ユーザーがアノテーションを付与せず作成したリソースでも、下記のように様々なアノテーションが付与される*kubectlを設定<pre> > $ kubectl get deployments -o yaml hello-minikube start*VirtualBoxapiVersion: apps/v1kind: Deploymentmetadata:[[File annotations:0753_minikube deployment.kubernetes.png|400px]]io/revision: "1" creationTimestamp: "2020-08-22T08:02:54Z" :</pre>*Ubuntu+KVMアノテーションとラベルをマニフェストに追記<pre>apiVersion: v1kind: Podmetadata: name: sample-pod annotations: annotation1: val1 annotation2: val2 labels:[[File label1:Minikube_kvmlab1 label2: lab2spec: containers: - name: nginx-container image: nginx:1.png|400px]]19</pre>
==[[Kubernetes]]クライアント==Podの削除====<pre>$ kubectl delete -f sample-pod.yaml pod "sample-pod" deleted</pre>===2つのコンテナを内包したPod===*公式なクライアントは、kubectlマニフェスト sample-2pod.yaml<pre>apiVersion: v1kind: Podmetadata: name: sample-2podspec: containers: - name: nginx-container image: nginx:1.19 - name: radis-container image: redis:6.0.7</pre>*kubectlを使用してクラスターと対話できるようになります適用<pre>$ kubectl apply -f sample-2pod.yaml pod/sample-2pod created</pre>*[[Kubernetes]] APIと連携するコマンドラインツール結果確認<pre>$ kubectl get pod --output wide*NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-2pod 2/2 Running 0 7m40s 172.17.0.6 minikube から利用する場合 <none> <none> > sample-pod 1/1 Running 2 2d 172.17.0.3 minikube kubectl version <none> <none></pre>
===kubectlインストールコンテナへのログインとコマンド実行===*-t 疑似端末（TTY)を生成し、-i 標準入力をコンテナに渡す* /bin/bashコマンドを実行する
<pre>
$ curl kubectl exec sample-pod -LO https://storage.googleapis.com/kubernetesi -release/release/$(curl t -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectlbash$ sudo chmod +x .root@sample-pod:/kubectl$ sudo install kubectl /usr/local/bin#
</pre>
===ダッシュボード[https://kubernetes.io/ja/docs/concepts/workloads/controllers/replicaset/ ReplicaSet]==*https://kubernetes.io/ja/docs/concepts/workloads/controllers/replicaset/*Podのレプリカを作成するリソース*レプリカ数=3でスケールさせたReplicaSet<pre>apiVersion: apps/v1kind: ReplicaSetmetadata: name: sample-rsspec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx-container image: nginx:1.19 ports: - containerPort: 80</pre>＊作成
<pre>
$ minikube dashboardkubectl apply -f sample-rs.yaml replicaset.apps/sample-rs created
</pre>
*確認**Podが3つ起動していることが確認できる<pre>$ kubectl get pods --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-2pod 2/2 Running 0 26h 172.17.0.6 minikube <none> <none>sample-pod 1/1 Running 2 3d2h 172.17.0.3 minikube <none> <none>sample-rs-9gxzs 1/1 Running 0 3m14s 172.17.0.7 minikube <none> <none>sample-rs-nsn86 1/1 Running 0 3m14s 172.17.0.9 minikube <none> <none>sample-rs-wcjsv 1/1 Running 0 3m14s 172.17.0.8 minikube <none> <none></pre>*ダッシュボードで確認[[File:Minikube_dashboardkubernetes_replicaset.png | 400px600px]]
===Kubernetes Deploymentを作る=[https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ Deployment]==*単純なHTTPサーバーであるechoserverという既存のイメージを使用して、Kubernetes Deploymentを作るhttps://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/*複数のReplicaSetを管理することで、ローリングアップデートやロールバックを実現するリソース*Kubernetesで最も推奨されるコンテナの起動方法*1つのコンテナでもDeploymentを使用すべき*Deploymentは新しいバージョンのリリースを管理する仕組み*デプロイされたアプリケーションをバージョンをまたいで表現する**Pod単体では自動で再起動されないし、ReplicaSetでは、ローリングアップデートが利用できない**PodもReplicaSetも変更されないコンテナイメージを取り扱うために作られている*フロー*#新しいReplicaSetを作成*#新しいReplicaSetのPod数を徐々に増やす*#古いReplicaSetのPod数を徐々に減らす*#上記を繰り返す*--portを使用して8080番ポートで公開#古いReplicaSetのレプリカ数を0で保つ
<pre>
</pre>
<pre>
$ kubectl expose deployment helloget pod --output wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESsample-deploy-5cc5cfccd7-6vq65 1/1 Running 0 33s 172.17.0.6 minikube <none> <none>sample-deploy-5cc5cfccd7-qjtbx 1/1 Running 0 33s 172.17.0.7 minikube <none> <none>sample-deploy-5cc5cfccd7-typeszcx5 1/1 Running 0 33s 172.17.0.3 minikube <none> <none></pre>*確認(ReplicaSet)<pre>$ kubectl get replicaset --output wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORsample-deploy-5cc5cfccd7 3 3 3 2m34s nginx-container nginx:1.19 app=NodePort sample-app,pod-porttemplate-hash=80805cc5cfccd7service</hellopre> *ダッシュボード[[File:kubernetes_deployment.png|600px]] ==[https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset/ DaemonSet]==*https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset/*ReplicaSetでは、Podの数が一致するとも確実に配置されるとも保証されない*DaemonSetは、ReplicaSetの特殊な形、各ノードにPodを一つづつ配置するリソース*各ノード上で必ず動作させたいプロセスのために利用することが多い <pre>apiVersion: apps/v1kind: DaemonSetmetadata: name: sample-minikube exposeddsspec: selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx-container image: nginx:1.19
</pre>
<pre>
$ kubectl get podNAME READY STATUS RESTARTS AGEhelloapply -minikubef sample-64b64df8c9ds.yaml daemonset.apps/sample-jzm5v 1/1 Running 0 11mds created
</pre>
<pre>
$ minikube service hellokubectl get daemonset -minikube -output wideNAME DESIRED CURRENT READY UP-TO-urlDATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTORhttpsample-ds 1 1 1 1 1 <none> 98s nginx-container nginx://1921.168.39.214:3142919 app=sample-app
</pre>
===クラスタのステータス=[https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/ StatefulSet]==*Serverとクライアントのバージョンhttps://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/*データベースなどステートフルなワークロードに対応するためのリソース*ReplicaSetの特殊な形**作成されるPodのサフィックスは数字のインデックスが付与**データを永続化する仕組みを持つ**Pod名が変わらない
<pre>
</pre>
*クラスタを構成しているコンポーネントを確認作成
<pre>
$ kubectl get componentstatusNAME STATUS MESSAGE ERRORcontrollerapply -f sample-manager Healthy ok stateful.yaml scheduler Healthy ok etcd-0 Healthy {"health":"true"} statefulset.apps/web created
</pre>
<pre>
$ kubectl get nodesstatefulset --output wideNAME STATUS ROLES READY AGE VERSIONCONTAINERS IMAGESminikube Ready web master 3h13m 0/3 2m19s v1.18nginx nginx:1.319
</pre>
<q>running "VolumeBinding" filter plugin for pod "web-0": pod has unbound immediate PersistentVolumeClaims</q>
*https://qiita.com/silverbirder/items/d3522237b28703a9adb6
*PersistentVolumeは、データを永続的に保存しておく場所のリソース。マネージドサービスを利用すると、デフォルトでPresistentVolumeが用意されている
*PersistentVolumeClaimsは、「PresistentVolumeを使わせて」というリソース
*PresistentVolumeのnameを指定し、applyすることで、初めてマウントができる
=====基本情報が最初に表示される===== Name: minikube [[R]]oleshttps: master Labels: beta.//kubernetes.io/arch=amd64 beta.kubernetes.ioja/os=linux kubernetes.iodocs/arch=amd64 kubernetes.ioconcepts/hostname=minikube kubernetes.iostorage/os=linux nodepersistent-role.kubernetes.iovolumes/master永続ボリューム(PersistentVolume)]== Annotations*https: kubeadm.alpha.//kubernetes.io/cri-socket: ja/vardocs/runconcepts/dockershim.sock node.alpha.kubernetes.iostorage/ttl: 0 persistent-volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Mon, 05 Aug 2019 23:17:24 +0900 Taints: <none> Unschedulable: false*ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供===PersistentVolume(PV)===*ストレージクラスを使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部*Nodeと同じようにクラスターリソースの一部*PVを使う個別のPodとは独立したライフサイクルを持っている=ノード上で動いているオペレーションの情報が表示される==PersistentVolumeClaim(PVC)===*それぞれのノードが十分なディスクとメモリを持っているかユーザーによって要求されるストレージ*Kubernatesマスターに対して正常であるかPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します Conditions:*クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます Type Status LastHeartbeatTime LastTransitionTime [[R]]eason Message===実例=== ---- ------ ----------------- ------------------ ------ --*https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ MemoryPressure False Tue, 13 Aug 2019 01:01:05 +0900 Mon, 05 Aug 2019 23:17:15 +0900 KubeletHasSufficientMemory kubelet has sufficient memory available====index.htmlをノード上に生成==== DiskPressure False Tue, 13 Aug 2019 01:01:05 +0900 Mon, 05 Aug 2019 23:17:15 +0900 KubeletHasNoDiskPressure kubelet has no disk pressure<pre> PIDPressure False Tue, 13 Aug 2019 01:01:05 +0900 Mon, 05 Aug 2019 23:17:15 +0900 KubeletHasSufficientPID kubelet has sufficient PID available$ minikube ssh [[R]]eady True Tue, 13 Aug 2019 01:01:05 +0900 Mon, 05 Aug 2019 23:17:15 +0900 Kubelet[[R]]eady kubelet is posting ready status$ sudo mkdir /mnt/data Addresses:$ sudo sh -c "echo 'Hello from kubernetes storage' > /mnt/data/index.html" InternalIP: 10$ cat /mnt/data/index.0.2.15htmlHello from kubernetes storage Hostname: minikube</pre>=====マシンのキャパシティ情報の表示=PersistentVolumeの生成==== Capacity:*ホストパスのPersistentVolumeを作成 cpu: 2*Kubernetesは単一クラスターで、ホストパスを開発とテストでサポートする ephemeral-storage: 17784772Ki*ホストパスPersistentVolumeは、ファイルやディレクトリをネットワークアタッチストレージをエミュレートしたものとして使用する hugepages-2Mi: 0*プロダクションのクラスターでは、ホストパスは使用すべきでなく、クラスタ管理者により、用意されたネットワークリソース（Google Compute Engine persistenｔ disk) などを使用する memory: 2038624Ki*クラスタ管理者は、StorageClassesも動的プロビジョニングに使用することができる pods: 110*ホストパスPersistentVolumeの例 Allocatable:<pre> cpuapiVersion: 2v1 ephemeral-storagekind: 16390445849PersistentVolume hugepages-2Mimetadata: 0 memoryname: 1936224Kisample-pv podslabels: 110=====ノード上のソフトウェアバージョンの表示===== System Info type:local [[Mac]]hine IDspec: 7ec5a55cfdc14693866eccf4e9a1228f System UUIDstorageClassName: 2C88347D-32CC-4F26-9AEE-1FED259A233Cmanual Boot IDcapacity: 1da81daa-4519-4f04-afe0-64efecedd7e7 Kernel Version storage: 4.15.01Gi OS ImageaccessModes: Buildroot 2018.05.3 Operating System: linux - ReadWriteOnce ArchitecturehostPath: amd64 Container [[R]]untime Version: docker path:"/mnt/18.9.6data" Kubelet Version: v1.15.0</pre> Kube-Proxy Version: v1.15.0*生成=====ノード上で動いているPod情報の表示=====<pre> Non-terminated Pods: (9 in total) Namespace Name CPU [[R]]equests CPU Limits Memory [[R]]equests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- -$ kubectl apply -f sample-pv.yaml kube-system coredns-5c98db65d4persistentvolume/sample-j24hp 100m (5%) 0 (0%) 70Mi (3%) 170Mi (8%) 7d1hpv created kube-system coredns-5c98db65d4-phtm8 100m (5%) 0 (0%) 70Mi (3%) 170Mi (8%) 7d1h</pre> kube-system etcd-minikube 0 (0%) 0 (0%) 0 (0%) 0 (0%) 7d1h kube-system kube-addon-manager-minikube 5m (0%) 0 (0%) 50Mi (2%) 0 (0%) 7d1h*確認 kube-system kube-apiserver-minikube 250m (12%) 0 (0%) 0 (0%) 0 (0%) 7d1h<pre> kube-system kube-controller$ kubectl get pv -manager-minikube 200m (10%) 0 (0%) 0 (0%) 0 (0%) 7d1houtput wide kube-system kube-proxy-wrgp5 0 (0%) NAME 0 (0%) CAPACITY ACCESS MODES RECLAIM POLICY STATUS 0 (0%) 0 (0%) 7d1hCLAIM STORAGECLASS REASON AGE VOLUMEMODE kubesample-system kube-scheduler-minikube 100m (5%) 0 (0%) 0 (0%) 0 (0%) 7d1h kube-system storage-pro[[vi]]sioner 0 (0%) pv 1Gi 0 (0%) 0 (0%) RWO Retain 0 (0%) 7d1h Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) [[R]]esource Available [[R]]equests Limits -------- -------- ------ cpu 755m (37%) manual 12s 0 (0%)Filesystem memory 190Mi (10%) 340Mi (17%) ephemeral-storage 0 (0%) 0 (0%) Events:</pre> Type [[R]]eason Age From Message ---- ------ ---- ---- ------- Normal NodeHasSufficientMemory 7d1h (x8 over 7d1h) kubelet, minikube Node minikube status is now: NodeHasSufficientMemory Normal NodeHasNoDiskPressure 7d1h (x8 over 7d1h) kubelet, minikube Node minikube status is now: NodeHasNoDiskPressure Normal NodeHasSufficientPID 7d1h (x7 over 7d1h) kubelet, minikube Node minikube status is now: NodeHasSufficientPID Normal Starting 7d1h kube-proxy, minikube Starting kube-proxy. Normal Starting 12m kubelet, minikube Starting kubelet. Normal NodeHasSufficientMemory 12m (x8 over 12m) kubelet, minikube Node minikube status is now: NodeHasSufficientMemory Normal NodeHasNoDiskPressure 12m (x8 over 12m) kubelet, minikube Node minikube status is now: NodeHasNoDiskPressure Normal NodeHasSufficientPID 12m (x7 over 12m) kubelet, minikube Node minikube status is now: NodeHasSufficientPID Normal NodeAllocatableEnforced 12m kubelet, minikube Updated Node Allocatable limit across pods Normal Starting 11m kube-proxy, minikube Starting kube-proxy ===クラスタのコンポーネント===*[[Kubernetes]]クラスタを構成する多くのコンポーネントが、[[Kubernetes]]自体を使ってデプロイされる*kube-system Namesspace内で動作====[[Kubernetes]] proxy====*クラスタ内のロードバランスされたSer[[vi]]ceにネットワークトラフィックをルーティング*クラスタ内の各ノードで動いている必要がある*DaemonSetというAPIオブジェクトが多くのクラスタではノードでプロキシを動作させるために利用される PersistentVolumeClaimの作成==kubectlコマンド==*Kubernetesでは、クラスタの操作は全て、Kubernetes Masterの APIを介して行われる*手動で操作する場合には、CLIツールの kubectl を利用するのが一般的 *Kubectl が Kubernetes Master と通信するには、接続先サーバー情報や認証情報が必要となる*デフォルトでは、~/.kube/config に書かれている情報を使用して接続を行う*設定を行う箇所は、clusters,contexts,users
<pre>
apiVersion: v1
</pre>
==[[Docker]]==
*[[Docker]]
*[[Docker コマンド]]
*[[Docker ネットワーク]]
===Dockerデーモンの再利用によるローカルイメージの使用===
*[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/#docker%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3%E3%81%AE%E5%86%8D%E5%88%A9%E7%94%A8%E3%81%AB%E3%82%88%E3%82%8B%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%BF%E7%94%A8 Dockerデーモンの再利用によるローカルイメージの使用]
https://hub.docker.com/
==Tips==
*[[WSL|WSL2でKubernetes/Dockerを動かす]]
===クイックスタート===
*https://kubernetes.io/ja/docs/setup/learning-environment/minikube/
<pre>
piroto@jinmu:~$ kubectl get node
NAME STATUS ROLES AGE VERSION
minikube Ready master 14m v1.18.3
piroto@jinmu:~$ kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
deployment.apps/hello-minikube created
piroto@jinmu:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
hello-minikube-64b64df8c9-42s98 0/1 ContainerCreating 0 11s
piroto@jinmu:~$ kubectl expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed
piroto@jinmu:~$ minikube service hello-minikube --url
http://192.168.39.238:30523
</pre>
*ローカル環境のクラスターについて詳細を確認するには、出力から得たURLをブラウザー上でコピーアンドペースト
[[File:Kubernetes quick start 01.png|600px]]
*Service,Deploymentの削除、クラスター停止、クラスター削除
<pre>
piroto@jinmu:~$ kubectl delete services hello-minikube
service "hello-minikube" deleted
piroto@jinmu:~$ kubectl delete deployment hello-minikube
deployment.apps "hello-minikube" deleted
piroto@jinmu:~$ minikube stop
ノード "minikube" を停止しています...
1台のノードが停止しました。
piroto@jinmu:~$ minikube delete
kvm2 の「minikube」を削除しています...
クラスタ "minikube" の全てのトレースを削除しました。
</pre>
===NodeでHello World===
*https://kubernetes.io/ja/docs/tutorials/hello-minikube/
© 2006 矢木浩人
