箱庭療法（はこにわりょうほう、独: sandspiel therapie、英: sandplay therapy）は、心理療法の一種で、箱の中にクライエントが、セラピストが見守る中で自由に部屋にあるおもちゃを入れていく手法。表現療法に位置づけられるが、作られた作品は言語化されるときもある。基本的に自由に見守られながら表現することが重要であるといわれている。現在は成人の治療にも使用されるが、もともとは遊戯療法から派生した。米国や欧州など、世界で用いられる手法であるが、日本でも幅広く用いられている。
1911年、SF作家のH. G. ウェルズ（Herbert George Wells）が自分の子供と床の上でミニチュア玩具を並べて遊んだ印象深い体験に基づいて、「フロア・ゲーム（Floor Games）」という本を書いた。その本を読んで感動したイギリスの小児科医でクライン派のマーガレット・ローエンフェルト（en:Margaret Lowenfeld）が世界技法（The World Technique)を作り、1929年に発表した。その後、スイス人のドラ・カルフ（Dora Kalff）がユング心理学を基盤としてさらに発展させ、「砂遊び療法」（Sandplay Therapy, Sandspiel Therapie)として確立した。
⇧ まさかの、「H.G.ウェルズ」がキッカケ。
箱庭療法は当初は主に子ども用のセラピーとして使用された。その理由として、子供や思春期の人間は複雑な概念や言語の構成が苦手であり、どちらかというと、遊びや象徴的な表現の中で、自己表現をすることが多く非言語的な手法による治療は有意義との意見がある。しかし、その後、子供だけでなく、広く精神障害を持つ患者に使用されている。
また、世界的に日本ほど、箱庭療法が急速かつ、広範に普及した例はなく、現在は日本から中国・韓国などの地域にも徐々に広まっている。また、ヨーロッパ・米国においても使用されている。
1985年に国際箱庭療法学会(International Society for Sandplay Therapy) が設立された。
⇧ 日本の普及率が高いらしい。
ユング研究所に留学中だった河合隼雄の友人が、カルフに日本人がスイスで研究していることを告げ、河合とカルフが会うことになる。カルフと会った河合は、箱庭療法を体験することになるが、箱庭を見た際に、直観的に河合がかつて小学生の頃に見た「箱庭遊びと似ている」と思ったという。河合隼雄は箱庭療法に接した際、欧米と比較して非言語的表現の多い日本の文化に適していると思い、日本へ導入したと語っている。（「箱庭療法」はSandplay Therapyの河合隼雄による訳である。）
⇧ 河合先生の直感にある「箱庭」については、Wikipediaさんによると、
⇧ 日本は「箱庭」の文化に親しんできたらしい。
「箱庭療法」が必要な気がしてきた今日この頃、どうも、ボクです。
まぁ、今回もまったく関係のない話でスタートを切ったわけですが、Kubernetes関連について調査ということで。レッツトライ～。
結論から先に言うと、Docker ToolBox で、kind（Kubernetes IN Docker）を使っている場合、kind（Kubernetes IN Docker）のコンテナ内のKubernetes cluster環境に対してkubectl でのアクセスができないため、KubeVirt の導入ができませんでした。
kind（Kubernetes IN Docker）のコンテナのIPアドレスが、「127.0.0.1」になってしまうので、Docker ToolBox だとアクセスできないかと。
ちょっと、自分はネットワーク詳しくないので、現状対応できませんでした（涙）。
なので、お時間のある方のみ、ご照覧ください。
KubeVirt って？
「コンテナ化できないけど、Kubernetes を使いたいな～」っていうニーズを満たす技術ってことですかね？
KubeVirt technology addresses the needs of development teams that have adopted or want to adopt Kubernetes but possess existing Virtual Machine-based workloads that cannot be easily containerized. More specifically, the technology provides a unified development platform where developers can build, modify, and deploy applications residing in both Application Containers as well as Virtual Machines in a common, shared environment.
Benefits are broad and significant. Teams with a reliance on existing virtual machine-based workloads are empowered to rapidly containerize applications. With virtualized workloads placed directly in development workflows, teams can decompose them over time while still leveraging remaining virtualized components as is comfortably desired.
⇧ 仮想マシンに依存してても大丈夫ってことかと。
GitHub の情報だと、Kubernetes のアドイン（拡張機能）ってことになるらしい。
KubeVirt is a virtual machine management add-on for Kubernetes. The aim is to provide a common ground for virtualization solutions on top of Kubernetes.
⇧ Kubernetes環境において、「仮想化ソリューション」の共通化をしてきたいってことらしい、つまり、Kubernetesで、仮想マシンも管理できるようにしようってことかと。
仮想マシンに依存したプロジェクトであっても、「仮想化ソリューション」の共通化ができるのであれば、「仮想化ソリューション」が、「コンテナ」であろうと「仮想マシン」であろうと、違いは吸収できるからノープロブレムってことになるのかな。
At its core, KubeVirt extends Kubernetes by adding additional virtualization resource types (especially the VM type) through Kubernetes's Custom Resource Definitions API. By using this mechanism, the Kubernetes API can be used to manage these VM resources alongside all other resources Kubernetes provides.
⇧ KubeVirtは、Kubernetes の 「CRD（Custom Resource Definitions）」によって作成されたAPIで、つまり、「Custom Resource」を使うってことらしい。
■Kubernetes's Custom Resource Definitions API
⇧ 「Custom Resource」は、Kubernetes の用意している「Resource」では自分のやりたいことができない時に、自分で「Resource」を作ってしまえ、という目的で用意されてるものかと、たぶん。
qiita.com
Kubernetes の使い方としては、基本的には、
Kubernetesクラスタを操作する際には、CLIツールのkubectlとYAML形式で書かれたManifestファイルを用いてKubernetes Masterに「リソース」の登録を行います。実際にはkubectlも内部でKubernetes MasterのAPIを叩いているだけなので、ライブラリやcurlなどでも操作することが可能です。
⇧ 「Resource」を登録するってことらしいので、「Custome Resource」も登録して使っていく感じなんすかね？
ただし、KubeVirt を機能させるためには、「Custome Resource」を登録するだけでは駄目らしく、
The resources themselves are not enough to launch virtual machines. For this to happen the functionality and business logic needs to be added to the cluster. The functionality is not added to Kubernetes itself, but rather added to a Kubernetes cluster by running additional controllers and agents on an existing cluster.
⇧ 「functionality」「business logic」も、クラスターに追加しないといけないらしい。
じゃあ、「functionality」「business logic」って何？っていうと、具体的な説明は無いんですな（涙）。
なんで、あくまで推測するしかないんだけど、「Custome Resource」の登録で「virt-controller」が追加された「API Server」を起動することで、
- 「functionality」
- 「virt-handler」
- 「business logic」
- 「virt-launcher」
- 「libvirt」
が追加されるってことですかね？
どこに追加されるのよってのが、kubeVirt の architecture に載ってるようです。
⇧ 灰色になってるのが、「functionality」「business logic」ってことになるんですかね？（ただ、「virt-controller」は、「functionality」「business logic」には含まれないかと、たぶん...。）
図を見てお気づきの通り、Podの中身が、通常だとコンテナになるところを、VM（Virtual Machine）にできるようです。
KubeVirt の詳細については、
KubeVirt consists of a set of services:
|
Cluster | (virt-controller)
|
------------+---------------------------------------
|
Kubernetes | (VMI CRD)
|
------------+---------------------------------------
|
DaemonSet | (virt-handler) (vm-pod M)
|
M: Managed by KubeVirt
CRD: Custom Resource Definitionkubevirt/components.md at master · kubevirt/kubevirt · GitHub
⇧ 「virt-controller」「VMI CRD」「vm-pod M」って3つのセットで構成されているらしいです。
KubevirtはVMとコンテナを共通の基盤で管理できるようなツールです。Kubevirtは例えば以下のような機能を提供します。
⇧ なるほど、Kubernetesで、コンテナ、VMの両方が管理（利用可能になる）できるようになるというところがポイントですかね。
⇩ ちなみに、Red Hut が公開してるPDFでも「KubeVirt」紹介されてるようです。
実際に導入してみる
Kubernetes環境があれば、導入できそうなので、実際に導入してみます。
Kubernetes環境については、
⇧ この記事で、導入したkind（Kubernetes IN Docker）を使っていきたいと思います。
とりあえず、 Kubernetes 環境が整っている場合、「KubeVirt」を導入するには、
- Deploy KubeVirt Operator
- Check for the Virtualization Extensions
- Deploy KubeVirt
- Install virtctl
って流れらしいんだけど...、早速、「KubeVirt Operator」って説明ないやんけ～...
Operator Pattern
Kubernetes によりコンテナのためのインフラストラクチャは抽象化され、自動化により管理コストは削減できるでしょう。しかし、実際の運用においてコンテナ管理の自動化だけで十分と言えるでしょうか? 例えば、データベースをコンテナとして動かしていた場合はサービス継続性を高めるために定期的なバックアップやレプリケーションが必要となります。また、コンテナの監視やKubernetes 自体のリソース監視なども必要となりますが、どのような項目を監視するべきでしょうか? Operator Pattern とは従来運用者が考慮するべきこのような課題を解決するためのベストプラクティスを Kubernetes 上で管理する仕組みです。
図:Operatorの概念図
Operator は独自のリソース定義を行う Custom Resource Definition(CRD) とリソースの制御を行う Controller から構成されます。CRD では Kubernetes の API を拡張し Pod/Deployment/Service といった標準リソースと同様に独自のリソースを定義します。それに対し Controller ではそれらのリソースの制御をし、利用者によって定義されたマニフェストファイルの内容にしたがい構成変更を実施します。
なお、先に述べた Kubevirt, Cluster API などはこの Operator Pattern を利用することで本来リソースとして定義されていない “仮想マシン”, “クラスター” などのリソースを Kubernetes 上で管理可能としています。
⇧ 上記サイト様によりますと、 「Operator」==「CRD（Custome Resource Definition） + Controller」 ってことらしい。
んで、Kubevirt を構築するのに必要なyamlファイルが、
⇧ で公開されてるんだけど、
- https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml
- https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-cr.yaml
の2つを使用していく感じになるらしい。「${KUBEVIRT_VERSION}」 は、シェルとかで、どのバージョンを使うかとかを指定すれば良いらしい。
最終的には、以下の Pod の数が、KubeVirt の全量ということになるらしい。（正確には、PodをDeploymentってものが包括してる？らしい）
⇧ Minikube の例だけど、kind（Kubernetes IN Docker）でも同じような感じになるかと。
で、自分は、KubernetesのMaster Node（kube-apiserver、または、API Server とかいろんな書き方されてるから、統一しろっての、を持つNode） については、Pod とか生成されないもんだと思ってたんですが、
⇧ 上記サイト様の情報によりますと、Master Node でも、 Podが生成されるんだそうな。
そんでは、実際に導入していこうと。
⇧ 上記サイト様を参考にさせていただきました。
まずは、仮想マシンを起動で。
仮想マシンが起動したらば、kind（Kubernetes IN Docker）のコンテナを起動して、Kubernetes環境を構築しておく必要があるので、コンテナ一覧を表示。
docker ps -a
kind のコンテナを起動で。
docker container ls
「1.Deploy KubeVirt Operator」の手順から。
まずは、使用するKubeVirtのバージョンをbashで使用する変数に設定します。
export KUBEVIRT_VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases|grep tag_name|sort -V | tail -1 | awk -F':' '{print $2}' | sed 's/,//' | xargs)
そしたらば、変数の中身を確認。
echo $KUBEVIRT_VERSION
変数の中身が確認できたら、「CRD：Custome Resource Definition」の作成と、Operatorの「Deployment」「Pod」を作成で。
はい、エラー。
なんか参照してるIPアドレスが、起動してる仮想マシンのIPと異なるんだけど...
どうやら、クライアントソフト「kubectl 」が参照してる設定ファイルの影響らしい。
⇧ 上記サイト様によりますと、Windowsの場合「C:\Users\[ユーザ名]\.kube」ってディレクトリに設定ファイルが存在するらしい。
んで、自分の場合、「Minikube」「kind（Kubernetes IN Docker）」の両方を入れているため、「kubectl」の設定ファイルが2つあることになり、
■「Minikube」の時に作成された「kubectl」の設定ファイル
■「kind（Kubernetes IN Docker）」の時に作成された「kubectl」の設定ファイル
「Minikube」のほうの「kubectl」の設定ファイルが使用されていた模様。
っていうか、「kind（Kubernetes IN Docker）」の「kubectl」の設定ファイルの『server：https://127.0.0.1:53446』って、仮想マシンに繋がるんだろうか...
まぁ、どっちにしろ、今の状態では、「Minikube」のほうの「kubectl」の設定が使われてしまうので、「kind（Kubernetes IN Docker）」のほうに切り替えたいんだけど、
⇧ 「Master Node」のIPアドレスが「192.168.99.101」で動いているという...っていうか、仮想マシンのIPアドレスと一致させる必要は無いんかね？
んで、「kubectl」が使用する設定ファイルを指定することは可能らしい。
⇧ 上記サイト様を参考に、現在のKubernetes環境を確認してみる。
kubectl config get-clusters
⇧ Oh, my gosh...
「Minikube」のKubernetes環境になってますね（涙）。
切り替えてみたけど、
駄目やんけ～！
コンテナにログインはできたけども...
⇧ 上記サイト様によりますと、「winpty」ってのを付けないといけないのは、また、「Git for Windows」の問題らしい...
そして、これ、いま思ったんだけど、Docker ToolBox でのkind（Kubernetes IN Docker）使用だと、kubectl で、Kubernetes環境にアクセスできないんじゃない？
なぜなら、kind（Kubernetes IN Docker）のコンテナのIPアドレスが「127.0.0.1」になってしまっているからかと...。
コンテナ内のproxyのbindをhost側につなげる際のhost側の待ち受けIP:PORT
PROXY_BIND_IP_PORT=127.0.0.1:18080
※ Docker Toolbox (VirtualBox) を使っている場合は、コンテナの待ち受けIPを 0.0.0.0 として、ブラウザに設定するプロキシは、VMのIPにする必要がある（VMのIPは以下のコマンド確認可能）。
GitHub - tksugimoto/docker-vpn-http-proxy: 複数のVPN接続を同時に行なうためのDockerコンテナ
⇧ やっぱり、というか、「kind（Kubernetes IN Docker）」のコンテナの仕様がDocker ToolBox の使用を考慮してないってことですかね...
⇧ 仮想マシンには繋がるんですけどね。
というわけで、多大な時間を浪費してしまったわけですが、
If you have go (1.11+) and docker installed GO111MODULE="on" go get sigs.k8s.io/kind@v0.5.1 && kind create cluster is all you need!
GitHub - kubernetes-sigs/kind: Kubernetes IN Docker - local clusters for testing Kubernetes
⇧ って言葉に完全に騙されましたわ...
いや、コンテナは確かに動くけどさ...kubectl でコンテナにアクセスできないとか意味ないじゃんね...
なので、Docker ToolBox 以外の環境ならイケるんではないでしょうか。
技術書典で出会った人に、kind（Kubernetes IN Docker）は、Docker ToolBox でもできるよ～って聞いてたんですけど、私にはレベルが高かったですかね...
今回も、泥沼にハマった挙句、解決できないというね...疲れましたね。
今回はこのへんで。
