kindでelasticsearchを動かす

Kubernetes IN Docker(kind)を使えば、helmとかで簡単にk8sにelasticsearchを動かせるかなと思い、試してみる。

elasticsearchのhelmチャートはhelm/stableとelasticの2種類あるが、現時点ではelasticの方は動かなかった…。elasticの方にはexamplesにはkindの例があるのだが、これもダメなので、がんばって調べないと動かせなそうなので、一旦、これは見送って、素直にhelm/stableを試す。

kindやhelmなどの必要なものは入れてある前提で、まずは、kindでk8sのクラスタを作成する。

$ kind create cluster 
 Creating cluster "kind" …
  ✓ Ensuring node image (kindest/node:v1.15.3) 🖼
  ✓ Preparing nodes 📦 
  ✓ Creating kubeadm config 📜 
  ✓ Starting control-plane 🕹️ 
  ✓ Installing CNI 🔌 
  ✓ Installing StorageClass 💾 
 Cluster creation complete. You can now use the cluster with:

 export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
 kubectl cluster-info

という感じでクラスタが簡単にできる。kindでいろいろな設定でクラスタを作ることもできるらしい。何も指定しなければ、kindという名前のクラスタができる。

$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
$ kubectl cluster-info
 Kubernetes master is running at https://127.0.0.1:36777
 KubeDNS is running at https://127.0.0.1:36777/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

KUBECONIGを設定すれば、kubectlコマンドが利用できる。あとはhelmを使うので、tillerに権限を付けて初期化しておく。

$ kubectl -n kube-system create serviceaccount tiller
 serviceaccount/tiller created
$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
 clusterrolebinding.rbac.authorization.k8s.io/tiller created
$ helm init --service-account=tiller --wait
 $HELM_HOME has been configured at /home/shinsuke/.helm.

 Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

 Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
 To prevent this, run helm init with the --tiller-tls-verify flag.
 For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

これ以降は普通にhelmでインストールすれば良い。

$ helm install --name my-release stable/elasticsearch
...
 From outside the cluster, run these commands in the same shell:

 export POD_NAME=$(kubectl get pods --namespace default -l "app=elasticsearch,component=client,release=my-release" -o jsonpath="{.items[0].metadata.name}")
 echo "Visit http://127.0.0.1:9200 to use Elasticsearch"
 kubectl port-forward --namespace default $POD_NAME 9200:9200 

という感じで、上記にあるようにkubectl port-forwardを実行すれば、localhost:9200でアクセスして確認することができる。

k8sのクラスタを破棄するには

$ kind delete cluster

とすれば削除できる。

カーネルパッチの当て方

最近、リリースされるたびにカーネルビルドをしている今日この頃だけど、リリースごとのカーネルパッチの当て方のメモ。

カーネルの差分パッチはkernel.orgからダウンロードできるけど、今のソースが5.3.5で5.3.6にしたい場合は、inc.patchからダウンロードして、たとえば、以下のような感じで当てる。

$ git clone https://github.com/marevol/linux-5.3-xps_13_2in1.git
$ cd linux-5.3-xps_13_2in1
$ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/incr/patch-5.3.5-6.xz
$ xzcat patch-5.3.5-6.xz | patch -p1

XPS 13用のLinuxカーネル5.3を作る

DellのXPS 13 2 in 1に5.4-rc1をビルドして入れたものの、APIのインターフェースが変わったりで、動かないものがあり、ちょっと使えなそうなので、5.3系に転がっているパッチを当てつつ、Ubuntu 18.04でしばらく利用していこうかと思う。

それをするためには、ソース管理もきちんとしておかないと厳しそうなので、githubにlinux-5.3-xps_13_2in1としておいた。とりあえず、パッチ用ブランチとか作って、しばらく使って大丈夫そうだったら、マージしていこうと思う。

XPS 13 2 in 1は性能とかサイズ感とかもいい感じのマシンだと思うが、Ubuntuで使いたい人がどれだけいるかは謎だが、とりあえず、普通の人並みのUbuntu環境として使えるようにはしておきたいところ…。

現時点ではブート時にオプション無しでも起動できるようになった。今後は、Thunderboltあたりを何とかしたいところ…。