問題タブ [openshift-origin]

特定のノードの過負荷を避けるための openshift の自動負荷分散に関して、短い一般的な質問があります。

現在、5 つのノードを持つ小規模なシステムを使用していますが、これらの機能は多かれ少なかれ類似しています。

何らかの理由で、openshift は常に node0 から始まり、最大ポッドまでいっぱいになり、node1、node2 などに移動します。バランスをとろうとする代わりに。

これにより、最初のノードの負荷が 70 以上と高くなり、最後のノードは完全にアイドル状態になります。

負荷が X を超える場合、ノードごとにそれ以上のノードをスケジュールしないように指定する方法はありますか?

ありがとう

Java アプリケーションのオープン シフトでポートを開こうとしています。しかし、アプリを実行すると、このエラーが発生します

何か案は？

ドキュメントによると、openshift オリジンが dockerコンテナーとして実行されている場合、コンテナーが削除されると、すべての構成と保存されたアプリケーション定義も削除されます。

私の質問は、コンテナーを実行している場合、構成を失うことなく openshift をアップグレードする方法はありますか?

openshift/origin docker image を実行すると、コンテナーのログにこのエラーが表示されます ( $ docker logs origin)。

Error running 'chcon' to set the kubelet volume root directory SELinux context

これは既知の問題ですか、それとも無視できますか?

私が使用したコマンドラインは docker run -d --name "origin" -e "http_proxy=$http_proxy" -e "https_proxy=$https_proxy" -e "no_proxy=$no_proxy" --privileged --pid=host --net=host -v /:/rootfs:ro -v /var/run:/var/run:rw -v /sys:/sys openshift/origin start --cors-allowed-origins='.*'

私のOSと環境に関するいくつかの情報： 3.12.28-4-default SUSE Linux Enterprise Server 12 (x86_64) VERSION = 12 PATCHLEVEL = 0 NAME="SLES" VERSION="12" VERSION_ID="12" PRETTY_NAME="SUSE Linux Enterprise Server 12" ID="sles"

永続ボリュームを使用しようとすると、openshift aws デプロイメントに問題があります。

これらは、mysql-persistent インスタンスをデプロイしようとしたときに発生するエラーの一部です。

- ポッド "mysql-4-uizxn_persistent-test" のボリュームをマウントできません: クラウド プロバイダーはボリュームをサポートしていません - ポッドの同期エラー、スキップ: クラウド プロバイダーはボリュームをサポートしていません

各ノード node-config.yaml に以下を追加しました

また、master-config.yaml に以下を追加しました

何かが欠けているだけなのか、既知の問題/回避策があるのか​​ はわかりません.

また、構成ファイルが変更されたことをopenshiftまたはkubernetesがどのように認識するかという質問もありますか?

また、状況を説明するために、 openshift-ansibleを使用して環境をデプロイしました。

そのイメージを本番環境で使用することが推奨されているかどうかを知りたいです。または、Openshift Natively をインストールする必要がありますか?

Docker イメージを本番環境で使用できる場合、新しいバージョンのイメージがリリースされたときにどのようにアップグレードすればよいですか? 新しい docker コンテナーを開始すると、すべての構成とアプリケーション定義が失われることはわかっています。それらを維持する方法はありますか？ボリュームのマッピング? どのボリュームをマップする必要がありますか?

私が使用しているコマンドラインは次のとおりです。 $ sudo docker run -d --name "origin" \ --privileged --pid=host --net=host \ -v /:/rootfs:ro -v /var/run:/var/run:rw -v /sys:/sys -v /var/lib/docker:/var/lib/docker:rw \ -v /var/lib/origin/openshift.local.volumes:/var/lib/origin/openshift.local.volumes \ openshift/origin start

PS。昨日尋ねた相対的な質問がありますが、同じ問題に焦点を当てていません。

2016 年 1 月 20 日の更新

/var/lib/origin2016 年 1 月 17 日より前にうまく機能した@Clayton のマッピング フォルダーの提案を試してみました。その後、ルーターやその他のアプリケーションを展開するときにFailed to mount 問題が発生し始めました。mapping に戻すと/var/lib/origin/openshift.local.volumes、今のところ問題ないようです。

Kubernetes を使用してマイクロサービスの展開を行うプラットフォームの作成に取り組んでいる間、Kubernetes 展開オブジェクトに依存関係を取得したいと考えています。ただし、ドキュメントhttp://kubernetes.io/v1.1/docs/user-guide/deployments.htmlを見ました次のように述べています。「Deployment オブジェクトは実質的に API バージョン v1alpha1 を持っていることに注意してください。Alpha オブジェクトは、将来のソフトウェア リリースで変更されるか、廃止される可能性さえあります」廃止または変更される可能性があります。新しいラベルを使用して rc を作成し、古い rc と新しい rc の両方で異なるラベルを使用して新しいポッドを作成し、古い rc からポッドをゆっくりと削除して古い rc を縮小するなど、同じ概念を自分たちで再実装する必要があります。新しいポッドを新しいrcにゆっくりと追加します。展開の計画または提案された変更は何ですか、またはその概念はより良い概念のために廃止されますか? また、なぜ OpenShift が Deployment オブジェクトを使用しなかったのか疑問に思っています。その時点で準備ができていなかったのですか?

誤解しないでください。私は警告が好きですが、実行するときに常にそこにある必要はありませんoc status -v。

マスターを再起動すると、ルーターとレジストリも再起動され、警告メッセージが表示されます。 Warnings: * container "registry" in pod/docker-registry-1-cena8 has restarted 3 times * container "router" in pod/router-1-lv4vn has restarted 4 times

レビュー後にクリアできますか?

突然、以前はデプロイできた一部のイメージをデプロイできなくなりました。次のポッド ステータスを取得しました。

アプリケーションが起動しません。Pod はコンテナーを実行しようとしていません。イベントページから、 を手に入れBack-off pulling image "172.30.84.25:5000/default/arix@sha256:d326ました。のタグで画像をプルできることを確認しましたdocker pull。

最後のコンテナのログも確認しました。なぜか閉鎖されていました。ポッドは少なくとも再起動を試みる必要があると思います。

問題をデバッグするためのアイデアが不足しています。さらに何を確認できますか?