minikube@WindowsをWSLから操作する(confをsymlink編)
はじめに
最近PCをMacからWindowsに買い換えました. Windows用にk8sの環境を整えたので,その内容をまとめておきます.
minikubeの設定ファイルをsymlinkでWSLから参照するために, minikubeのオプションを利用しその中身を確認するところがハイライトです.
[toc]
以下のような環境を目指します.
- minikubeの構築はWIndowsのVIrtualBox上でよい
- オペレーション (
kubectl
を使う)する環境はLinuxがいい - Linuxは起動が軽いほうが良いので,VirtualBoxではなくWSLを使う
※kube-prompt
は下記のGIFを見てもわかる通りめっちゃ便利!!!
手順
minikubeのインストール
GitHub - kubernetes/minikube: Run Kubernetes locally こちらを参考にminikubeをインストールします.
コマンドプロンプトから以下のようにバージョンが確認できれば大丈夫です.
[Windows]
>minikube version
minikube version: v0.32.0
WSLの準備
今回ディストリビューションはUbuntu 16.04.5 LTS
を使いました.
また,以下を参考にkubectl
を使えるようにしておきます.
Install and Set Up kubectl - Kubernetes
[WSL]
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4", GitCommit:"f49fa022dbe63faafd0da106ef7e05a29721d3f1", GitTreeState:"clean", BuildDate:"2018-12-14T06:59:37Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"
こちらもバージョンが確認できれば大丈夫です.
なお,WSL操作の端末は以下のwslttyを使いました.
デフォルトの端末だとkube-prompt
が使えなかったためです.(TUIが崩れる)
GitHub - mintty/wsltty: Mintty as a terminal for Bash on Ubuntu on Windows / WSL
minikubeの設定と起動
今回のミソの部分です,以下のコマンドを実行します. オプションの説明などは後程行います.
[Windows]
#認証認可の証明書をハッシュ化
> minikube config set embed-certs
※何も出力されない
# 確認
>minikube config view
- embed-certs: true
※↑この項目を確認
# 起動
> minikube start
WSLから接続
[WSL]
# minikubeの設定ファイルが参照できるか確認します
$ cd $HOME
$ ls -l /mnt/c/Users/hoge/.kube/config
# 設定ファイルへのsymlinkをHOMEに作成する
$ ln -s /mnt/c/Users/hoge/.kube/config minikube-config
minikubeの設定ファイル/mnt/c/Users/hoge/.kube/config
を参照しやすいようにWSL上にシムリンクを作成します
あとは接続確認するだけ
[WSL]
# 接続確認
$ kubectl get nodes --kubeconfig=minikube-config
NAME STATUS ROLES AGE VERSION
minikube Ready master 13h v1.12.4
環境変数KUBECONFIG
にこれを追加すれば
引数なしでも読み込んでくれる.
[WSL]
export KUBECONFIG=$HOME/minikube-config
この状態で kube-prompt
を使えば快適!!
オプションminikube config set embed-certs について
今回のキモであるこのオプションについてみてみます
このオプション追加の意図とPRは以下から確認できます. - minikube and WSL | Jason Stangroome - Allow certificates to be optionally embedded in .kube/config by jstangroome · Pull Request #3065 · kubernetes/minikube · GitHub
このオプションのありなしで具体的に何が変わるのか,確認してみます.
オプションがない/falseとき
minikube config set embed-certs: false
の場合です.
minikubeの設定ファイルを見るとクラスタやユーザの認証認可のための証明書へのファイルパスがWindows形式で記載されています.
$ cat config.tmp |egrep 'certificate-authority|client-certificate|client-key' | cut -c 1-40
certificate-authority: C:\Users\hobe\........
client-certificate: C:\Users\hobe\........
client-key: C:\Users\hobe\........
これをWSLから利用するには,kubecrl config set-*
コマンドで設定が必要で,そのためにWindowsとWSLでのパスの読みかえも必要になってきます.
また,minikubeのstop/startでIPも変わるため少々面倒です.
オプションがあるとき
minikube config set embed-certs: true
の場合です.
$ cat config |egrep 'certificate-authority|client-certificate|client-key' | cut -c 1-40
certificate-authority-data: LS0tLS1C.......
client-certificate-data: LS0tLS1CRUd.......
client-key-data: LS0tLS1CRUdJTiBSU0E.......
3つの証明書の内容がbase64
で暗号化され設定ファイルに埋め込まれています.
OS関係なく読み込めるというわけですね.
まとめ
参考サイト
Azure Kubernetes Service (AKS)クラスタをTerraformで構築する
はじめに
これまで手動で行っていた個人ユースのAzure Kubernetes Service (AKS)クラスタの構築を, 公式のドキュメントを参考にTerraformでのものに変更した.その際のメモ.
[toc]
成果物
GitHub - mickey390/aks-terraform: AKSのクラスタをTerraformでおこなう
気になる点
ログのワークスペース名はユニークに
ログのワークスペース名は、Azure全体?でユニークでないとだめっぽい. クラスタを再構築することも鑑み,ひとまずランダムな数値を名前に入れた.
* azurerm_log_analytics_workspace.test: operationalinsights.WorkspacesClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status= Code="Conflict" Message="The workspace name 'testLogAnalyticsWorkspaceName' is not unique" Target="name"
Dashboardへの権限付与
Azureのコンソールに,k8sへのダッシュボード表示リンクがある↓.
その際に,権限がなくリソースが表示されない場合は↓を実施.
kubectl create clusterrolebinding kubernetes-dashboard \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:kubernetes-dashboard
利用可能なk8sのversionを確認
以下のコマンドで確認した
az aks get-versions -l japaneast | fzf
利用可能なVMのサイズの確認
ドキュメントを見つけられなかった. Cloud Shell(bash)で以下のコマンドを入力しつつ<tab>を2回押すと利用できる?らしいVMの一覧が出てきた.
az aks create --l japaneast -s Standard_ <tab押す*2> Standard_A1 Standard_D13_v2 Standard_D64s_v3 Standard_DS3 Standard_F16s Standard_GS5 Standard_A1_v2 Standard_D13_v2_Promo Standard_D64_v3 Standard_DS3_v2 Standard_F16s_v2 Standard_GS5-16 ・・・・・・・・
デフォルトはStandard_DS2_v2
だが,お高いのでひとまずStandard_B2s
にした.
簡単にアプリケーションをデプロイしたが支障なく動いた.
バーストするタイプのインスタンスらしいので、リソースに注意.
https://github.com/Azure/azure-cli/pull/5393
まとめ
参考
InSpecをAWS Lambdaで動かす
はじめに
AWS Lambdaでrubyの実行がサポートされたので,前回のawspecに引き続き InSpecをLambda上で動かして見たいと思います.
InSpecはChefが中心となって開発されているOSSで、 Rubyで記述されたインフラに対するテストフレームワークです. Serverspecやawspecと似ていますが, セキュリティやコンプライアンスのチェックを目的として開発されたようです. 詳しい背景やServerspecとの違いなどは,以下のブログ記事(とその和訳)を読むとわかりやすいです.
The Road to InSpec - Chef Blog [和訳] InSpecへの道 #getchef - クリエーションライン株式会社
特徴の一つとして,テスト対象をOSのみならず AWS/Azure/GCPと複数のクラウドベンダをサポートしている点があるかと思います. InSpec Resources Reference
[toc]
続きを読む