安価なGKE（k8s）クラスタを作って趣味開発に活用する - えいのうにっき
tl;dr GKEでk8s（kubernetes）クラスタを作成すると、各ノードはGCEインスタンスとして起動する GCEインスタンスには preemptible モードが指定でき、これはGKEクラスタとして起動するノードに対しても指定可能 GCEのf1-micro無料枠の適用と合わせて、この運用費用は約 $7.68/month 動機 GKEクラスタを維持する最安料金ていくらだろー— a-know | Daisuke Inoue (@a_know) 2018年6月11日 趣味開発用途として手軽にあれこれ試すことができて、それでいてできるだけ安くあがるコンテナオーケストレーション環境（k8s環境）がほしい。 k8sそのものを運用したい・そのノウハウを学びたいというわけではないのでマネージドサービスがいい 「k8s上でアプリケーション・サービスを運用する経験」がしたい その上で、できるだけ安く
なぜGKEのノード自動アップグレードでアプリケーションサービスが停止するのか - Qiita
概要 GKEに用意されているノードの自動アップグレードは便利ですが、インスタンスの再起動を考慮していない構成・設定だとアプリケーションサービスが停止します。 解決している問題は少ないですがアプリケーションサービスが停止するケースと解決方法をまとめました。 環境 Kubernetes(GKE): >= v1.6 アプリケーションサービスが停止するケース Podの配置が偏っている spec.replicas: 2のDeploymentをapplyすると、以下の図のように1つのインスタンスに偏るケースが発生します。 ノードのアップグレードは1台づつkubectl drainするため、PodAが同じタイミングでterminateされます。 この状態になるとPodAと通信ができないので、アプリケーションサービスの停止につながります。 解決方法 PodDisruptionBudgetを設定する kub
GKEでCloud Storageをマウントしてみる - Toku's Blog
この記事は CyberAgent Developers Advent Calendar 2016 の3日目の記事となります。 では早速本題に。 やろうと思ったわけ 思い立ったからです。 とか言う冗談はいいとして。 Cloud Storage上に対象のファイルが存在した場合、そのファイルを返す。という仕組みを作ろうと思いました。 真っ先に思いつくのはアプリでファイルの存在確認後、存在したらそれを返すというものでした。 が、少し違うアプローチで、FUSE(Filesystem in Userspace)のGCS対応しているgcsfuseを使用してコンテナに マウントしてnginxで返す、という構成をやってみようということになりました。 この仕組みでいけば アプリの実装がいらない アプリが死んでてもレスポンスが返せる という感じで利点が見え、検証してみることに。 コンテナの作成 フロントに置くn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
