橋本修太です
Geeko Magazineに書いていたのですが、ちょっと前、確かkubernetes 1.12の時は、flannel 1.10を適応しようとすると、エラーとなって適用出来ませんでした。
それが、flannelがバージョンアップして解決したようです。今では以下のコマンドでネットからflannelを適応する事が出来ます。
kubectl apply -f https://0y.at/kubicflannel
Kubicが適応できるバージョンにショートネームをあてたようですね。
インストールの全体記事はこちらです。
それでは良いコンテナライフを。
橋本修太です
さて、突然ですが、今私のKubernetes環境はこんな感じになっています。
KVMは仮想マシン、KubicはopenSUSEのKubernetes専用ディストリビューション、masterやnodeはKubernetesクラスタでの役割を表しています。
ルーターに有線でデスクトップが繋がっていて、そこに３つKubicを走らせています。
また、ルーターはWiFiルーターに繋がっていて、WiFiでノートパソコンと通信、そのノートパソコンの上にも３つKubicが走っています。
それをですね、こうしたいのです。
デスクトップのnodeを、ノートパソコンのKubernetesクラスタに組み込みたいのです。
ノートパソコンは、メモリは16G積んでいて少し余裕はあるものの、CPUはcore i5で、KVMをこれ以上増やすのは難しいです。
そこで、クラスタの利点を活かして、デスクトップからnodeを引っ張ってくるわけです。
KVMはデフォルトで閉じたネットワーク（ホストの外側からは中にアクセス出来ないネットワーク）を作成します。ただ、これはNATなので、ゲストからホストの外側にはアクセス出来ますが・・・
そこで、色々とやってみた結果、次のような方法でホストの外からのアクセスが出来ました。
検証や調査等はおいおいやっていくとして、それぞれの設定を書いてみたいと思います。
今回は【ノートPC】編、次回は【デスクトップPC編】です
グーグル先生に教えてもらって、いくつかの方法を試したりしたのですが、どれも挫折してしまいました・・・
どうやら、ブリッジはレイヤー2で転送するものらしいのですが、WiFiはレイヤー2転送に対応していないというのが、WiFiでのブリッジ作成が難しい理由の大きなところらしいです。・・・いまいちピンとこないので、後ほど詳しく調べてみたいと思います。
parproutedはarpをプロキシするものとの事です。また、etablesはEthernetフレーム用iptablesとの事です。parproutedはopenSUSE Leap15で上手く動かせられなかったり、ebtablesが意図した通り設定出来なかったりして、挫折してしまいました。
Facebookでそんな事をなげいていたら、Saputro Aryuliant氏より、「KVMのバーチャルネットワーク設定して、iptablesでマスカレード設定すればいけるよ」とのお助けが。
「ホストPCの外から、ゲストPCにアクセスできる？」と聞くと、「iptables設定すればいけるよ」とのことでしたので、早速試してみることに。
ルーティングでネットワークを作成します。
設定はvirt-managerでこんな感じです。
編集 > 接続の詳細
から、「仮想ネットワーク」タブを選んで、左下のプラスのアイコンをクリックして追加します。
デバイスにwlan0（WiFi）、方法にルーティングを指定している所がポイントです。
これ、デフォルトのNATネットワークだとだめなのかな？
まず、ノートPCでipv4のフォワードを有効にします。
sudo sysctl -w net.ipv4.ip_forward=1
これは再起動するとクリアされてしまいますので、常に設定したい場合は /etc/sysctl.d/の中に、{好きな名前}.confという名前で設定ファイルを作成して、その中に記述しておけばOKです。
確認は以下のコマンドで。
sudo sysctl -a
設定項目が表示されますので、grep -i forwardとかで絞ると楽に確認できます。
それから、同じくノートPCにマスカレードを設定します。
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE
これで、ノートPCの上で走らせているKVM上のKubicが、自由に外にアクセスできるようになりました。
とりあえず、アクセスしたいマシンやKVM上のKubicで、以下の設定を行いました。
ip -4 route add 192.168.100.0/24 via 192.168.0.12
192.168.100.0/24行きのパケットは、192.168.0.12（ノートPCのIPアドレス）をデフォルトゲートウェイにしてね、という設定です。
これで、デスクトップや、そこで走っているKVM上のKubicから、ノートPC上のKubicにアクセスできるようになりました。
・・・もちろん、デスクトップ上のKVMも、ブリッジ設定して、ホストの外へアクセスできるようにすれば、です。その様子はまた次回に。
橋本修太です。
例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。
kubectlでdeploymentのyamlをapplyしても、DESIREDからCURRENTに移行しなくなった
要するに、新しいpod（Dockerで言うところのコンテナ）が動かなくなった、という事です。
不明
直前に、nginx-ingress入れたりしていたんですけど、それでしょうか・・・・
crictlで、Exitedなkube-controller-manager-****を削除したら、動き出しました。
現象発生時、何かを調べたとは思うのですが、忘れてしまいました・・・とりあえずKubernetesを再起動させました。
$ kubectl drain <node name> –delete-local-data –force –ignore-daemonsets
$ kubectl delete node <node name>
$ kubeadm reset
$ reboot
いつもこの方法なんですけど、これでいいんでしょうか？
そして、いつもどおり起動していきます。
kubeadm init –cri-socket=/var/run/crio/crio.sock –pod-network-cidr=10.244.0.0/16
cp -i /etc/kubernetes/admin.conf ~/.kube/config
kubectl apply -f ./kube-flannel.yml
最後の、flannelのymlは、githubから落としてきたものです。詳細はGeeko Magazineをご覧ください。ただ、README.mdに書いてある、以下のコマンドでも正しく動きそうですね。flannelかな？と思って、こちらで試してみたのですが、動作は同じようでした。masterなので、いつどういう動作をするかは、保証されないのでしょうが・・・
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
そして、同じ現象に出くわします。nodeの状態を以下のコマンドで確認するのですが、
kubectl get nodes
ずっと、STATUSはNotReadyのまま。
kube-system（というnamespaceで配置される、システム系のpod）を確認します。
kubectl get pods –all-namespace
すると、kube-controller-manager-****（****は、マスターのマシン名）のSTATUSが、CreateContainerErrorとなったまま。
ふーむ・・・ここでグーグル先生に泣き付く事小一時間。こんな感じで辿りました。
journalctl
Kubicは、Kubernetes関係のログはほぼここに入っています。いるはずです。いると思っています。
すると、こんな感じのログが立て続けに出力されていました。
pod_workers.go:190] Error syncing pod
****************** (“kube-controller-manager-linux-riis_kube-system(*********************)”), skipping: failed to “StartContainer” for “kube-controller-manager” with CreateContainerError: “the
container name \”k8s_kube-controller-manager_kube-controller-manager-linux-riis_kube-system_********************_**\” is already in use by \”************************************
\”. You have to remove that container to be able to reuse that name.: that name is already in use”
******はマスクです。ランダム英数字が入っています。また、linux-riisが、masterのマシン名です。
podのログも確認してみましたが、同じようなログが出力されていました。（はずです・・・もしかしたら、コンテナを生成できなかった、程度だったかもしれません・・・）
kubectl logs pods/kube-controller-manager-****（マシン名） -n kube-system
-nオプションで、namespaceを指定しないと、見つからないと言われるので注意です。
ふむふむ、どうも、IDだかがかぶってしまって、新しいkube-controller-managerを起動できないようです。
ここでイメージとコンテナの確認です。Kubicはcri-oを使っているため、コンテナ関連のコマンドはcrictl、サービスはcrioになります。crictlのホームページはこちら。Dockerと似たような感じで使えるのではないでしょうか。ちなみに、このコマンドが入っているパッケージはcri-toolsです。
サービスステータスをチェックします。
systemctl status crio
CNIのデフォルトネットワークが見つからないよ、というエラーが見えますが、flannelを適応すれば直るでしょう・・・直ると信じたいです。（事実、直りました。）
では、コンテナの確認です。
crictl ps -a
すると、Runningとなっているものと、Exitedとなっているもの、２つのkube-controller-manager-****が。その他にも、kube-apiserver-****や、kube-scheduler-****も同じように、二種類。
Exitedとなっているものは不要なので（不要で終了したのでExitedなはずなので）、削除しましょう。
crictl rm ****（コンテナIDです。先のcrictl ps時に表示されます。）
そして、システム系のpodを確認。
kubectl get pods –all-namespaces
すると、なんと、kube-controller-manager-****が、Runningに変わっているではありませんか！
ただ、ちょっと待ってkubectl get nodesしても、NotReadyだったので、同じくExitedだった、kube-apiserver-****と、kube-scheduler-*****のコンテナも、削除しました。
そして待っていると・・・・無事、masterがReadyになりました。
後は、ワーカーNodeのkubeadm joinもすんなり動き、正常稼働に戻りました。
この記事は openSUSE Advent Calendar の 20日目です。完走も見えてきました。
さて、今日は Twitter などでときどき質問が飛ぶ Google Chrome のインストール方法です。
openSUSE では Google Chrome の OSS 版である Chromium がパッケージとして提供されています。普通のウェブサイトを見る分にはこれでよいのですが、Flash Player が必須なウェブサイトや、DRM で保護された不自由なコンテンツを見るために、ときどき Chrome が欲しくなるときがあります。
それでは、インストール方法です。
(1) Google のリポジトリのGPG 公開鍵のインポート
Chrome のパッケージを署名している鍵の公開鍵をインポートします。この手順を飛ばすとパッケージの署名チェックでエラーになってしまいます。
wget https://dl.google.com/linux/linux_signing_key.pub sudo rpm --import linux_signing_key.pub
こちらのページにも手順が書かれています:
https://www.google.com/linuxrepositories/
(2) Chrome をダウンロードする
ブラウザで Linux 用の Chrome のrpmファイル（Fedora/openSUSE用）をダウンロードします。
https://www.google.com/chrome/
※Windows などからダウンロードする場合は、画面の下部に「他のプラットフォーム」というリンクから Linux 版のダウンロード画面にたどり着けます。
(3) セットアップを実行する
ダウンロードした rpmファイルを zypper でインストールします。
cd ダウンロード sudo zypper in ./google-chrome-stable_current_x86_64.rpm
おわりに
以上、Chrome のインストール方法でした。Amazon Prime などの動画配信サイトが見られないといったような場合は、Chrome を試してみて下さい。
明日は「openSUSEでディスクの健康状態を取得」です。
openSUSE Advent Calendar ももう17日目ですね
今日はこの blog が動いている geeko.jp のサーバーのメンテナンスの話です。このサーバーは ConoHa で動いており、13.1, 42.3 とアップデートをしてきました。今回は42.3 から 15.0 にアップデートしました。
いつもオンラインでアップデートしています。クラウドの場合、ディスクイメージをダウンロードして、ConoHa にアップロードし、インストーラを起動してアップデートはちょっと大変です。オンラインアップデートであればリポジトリの URL を書き換えて zypper dup するだけなので簡単です。
リポジトリのURLを書き換える方法はいくつかありますが、YaST のリポジトリ設定からバージョンの部分を書き換えるのがオススメです。
zypper dup --download-only zypper dup
ディスク容量には余裕があるので、一度ダウンロードが完了するのを待ってから、アップデートを適用しました。
15.0 には、これまで提供されてきた mysql-community-server のパッケージがなく、完全に Maria DB に置き換えられています。やったことは以下の3つです。
設定ファイルは、新しい設定ファイルをそのまま使いました。一応、これまでのファイルと新しい設定ファイル /etc/my.conf.rpmnew を比較したところ、内容はかなり増えていますが、コメントアウトされた部分以外はほとんど同じでした。
+bind-address = 127.0.0.1 +log-error = /var/log/mysql/mysqld.log +secure_file_priv = /var/lib/mysql-files -sql_mode='' +sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Leap 15.0からCentOSなどでお馴染みの firewalld が使えるようになりました。これまでのSuSE Firewall2 も引き続き使うことができます。移行する場合は手動で SuSEfirewall2 パッケージを削除して、firewalld をインストールする必要があります。
Firewalld では次のように使用したいサービスのポートを開けられます。
firewall-cmd --permanent --add-service https firewall-cmd --reload
アップデートしたついでに、Webサーバーを TLS に対応させました。証明書は無償の Let’s Encrypt で取得しました。
Let’s Encrypt の certbot コマンドを使えば、証明書の取得から Apache の設定まで1コマンドです。このあたりの細かい話は Geeko Magazine SP 2018冬号に書いていますので、ぜひ読んでみて下さい。
geeko.jp で動いていた WordPress や Vanilla Forum、Pukiwiki はそのまま動きました。このあたりは 13.1 からのアップデートと比べると、とても楽でした。
ということで、大したことではありませんが、geeko.jp のサーバーをアップデートしたときの話を書いてみました。42.3のサポート期間はあと半年くらいですので、これから 15.0 にアップデートする方は参考にしてみて下さい。
明日は鹿さんが USB オーディオの話の続きを書いてくれるそうです。
この記事は、「openSUSE AdventCalendar 2018」16日目の記事です。
皆さんおはようございます。橋本修太です。
さて、先日jaのMLにこんな投稿がありました。
【意訳】
openSUSE(Kubic)でCloud Foundry動かしたことある人います？
Kubicのキーワードが目に止まり、はて、Cloud Foundryとは？と思った私は、調査してみました。
本記事は情報収集のみとなります。「やってみた」は次の機会になりますこと、ご了承ください。
ホームページはこちら。概要を纏めてくださっているページが幾つか有りますので、それらを見ていきますと、どうやら、webアプリケーションのソースコードをpushするだけで、ビルド・デプロイを自動で行ってくれる、オープンソースのソリューションの模様（商用版もあり）。イメージとしてはherokuに近いですね（こんな記事もありました）。
「アメリカのFortune 500企業のうち約半数が導入済み」といった謳い文句も見られますね。
いくつかあるようです。Cloud Foundry自体、複数のコンポーネントで構成されるソリューションなので、手順があったり、インストールを支援してくれるソリューションがあったりします。
また、Pivotal、SUSEなどがチューニングしたソリューションもあって、それぞれ強みがあるようです。
ちなみに、Cloud Foundryとやりとりを行うコマンドラインツール群、cf-cliは、openSUSEにパッケージがありました。（動くかな？）
PCFとは、Pivotal Cloud Foundryの略です。Pivotalはクラウドで有名な会社のようです。
ここが展開している、ローカル開発用のCloud Foundry、PCF-DEVが、インストールしてみるには丁度良いよ、という投稿もstack overflowで見たりしました。
構成としては、Linux（私の場合openSUSE）の上に、VirtualBoxを動かし、その中でPCFを動かすようです。
インストール方法はこちら。
BOSHは、Cloud Foundryの導入・運用を制御するソリューションのようです。
単一マシンに展開したり、クラスタ構成に展開したりもできるようです。
通常、Cloud Foundryをインストールと言えば、この方法が正攻法？なのかもしれません。
SUSEも、Cloud Foundryには力を入れていて、チューニングしたソリューションを持っていました。
githubはこちら。
主なチューニング点として、以下が挙げられていました。
Steamcellだの、stackだの、previewだの、ちょっとピントこない単語が沢山・・・これらはおいおい調べていく事にしまして、1番目に付いて、もともとCloud FoundryはKubernetesの上で動くようには作られていなかったのですが、そこをSUSE等が開発したとの事です。
件のgithubには、on Kubernetesで動かす方法も記載されているのですが、ここではPCF-DEVと同じように、VMの上で動かす方法を。
Disclaimerに、「openSUSE 42.xは、libvirtでテストしてますよ」とあります。ここが42.xになっているのが、ちょっと気になるところですが・・・（あと、SUSEのgithubなのに、openSUSEがOpenSUSEになっている所とか）
あとは、Deploying SCF on Vagrantのセクション通りにやっていけばよさそうです。
ただ、要件にいきなり「メモリは16G以上は用意してね」とあって、私のデスクトップはもう無理状態です。
C.で触れましたが、Kubernetesの上にインストールできるのが、SCFの強みとの事。Helmでインストールするようですね。インストールページには要件等書いてありますので、適応させて行けば動くでしょうか？
ちなみに、環境チェック用スクリプトがあるのですが、Kubic上で走らせた所、半分ぐらいerrorとなってしまいました。
駆け足で情報収集だけしたのですが、結構複雑な構成をしていて、ちゃんと理解しようとするとそれなりのボリュームになりそうです。使う側は、ソースコードをcf pushすれば、デプロイまで完了、とやりやすい事この上無いですね。
では、16Gメモリを積んでいるノートPCがあるので、近いうちにやってみたをやってみたいと思います。
明日は @ftake さんの、geeko.jpをメンテナンスした話ですね。塩漬けに近かったサイトですので、色々と面白い話題が出てきそうです。こうご期待。
この記事は、「openSUSE AdventCalendar 2018」15日目の記事です。
今、諸事情でぜーんぜんアップグレードしていない、openSUSE13.2(32bit)のマシンがあります。さすがに何とかしたいのですが、最近のopenSUSE は 64ビット。アーキテクチャが違います。果たしてそのままアップグレードできるのでしょうか?
ということで、実際にどうなのか、実験してみることにしました。
まずは、openSUSE 13.2 (32ビット版)をテスト用の仮想環境にインストール。ただ、13.2は、すでにopenSUSEのサイト(ミラー含む)には存在していません。探しまくったあげく、ここにあることを発見。ダウンロードしました。一応 zypper update も動いたので、可能な限り最新版にしておきます。
次に、Leap 15.0 のDVDイメージを仮想環境にマウントし、DVDイメージからブート。アップグレードを選びます。一応通常通り起動し、アップグレードが始まります。しかし途中でアーキテクチャが違うという警告メッセージが出てしまいました。
警告なので、ここは取りあえず「続行」を選び、先に進むことにします。その後は特に警告が出ることもなく、無事アップグレードが終わり、Leap 15.0(64ビット版)にアップグレードができたようでした。
ただ、アップグレードすると、各ソフトウェアのバージョンもかなり上がります。とえば Samba は4.2.4から4.7.10になります。当然機能差があるので、個別に変更点を吸収していく必要があります。
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
