以前書いた"コンテナストレージの基礎理解"の改変版です。
Red HatでOpenShiftのサポートエンジニアをしているDaein(デイン)です。 OpenShift 4.5(Kubernetes 1.18)からstartupProbeがBeta機能としてデフォルトで利用できるようになりましたのでどのような機能であるか確認していきます。 関連リリースノートは以下のリンクです。 github.com Probesとは これまでlivenessProbeとreadinessProbeは、安定的なサービスが提供できるようにコンテナの起動状態を定期的にチェックし、正しく起動できなくなったコンテナを再起動させたり、外部からのアクセスを遮断させたりする機能を提供していました。 詳しい内容や詳細は次のリンク先をご参照ください。 docs.openshift.com kubernetes.io 今回は新しく追加されたstartupProbeという起動フェーズを
こんにちは!Red Hatの石川と申します。 昨年よりOpenShiftのテクニカルサポートエンジニアとして働いております。 まだまだOpenShift勉強中の身ですが、日々の業務で気付いたことなどを少しずつ記事にしていけたらと考えております。 今回はService Accountの認証の仕組みがどのようになっているかについて触れてみたいと思います。 Service Accountって? Service Accountは通常のUserとは別に、Podや各種コンポーネントがAPI呼び出しを行うために設計されたKubernetesのオブジェクトです。JenkinsやTravis CIなどでアプリケーションを自動化する際にも利用されます。 Service AccountはUserと違い、特定のタスクを実行することを目的に作られていますので、特定のnamespaceに紐づいています。ただし、nam
kubernetesクラスタを運用する時、nodeにシステムのリソースを確保していますか? 私は全く気にしていませんでした、そしてちょっとした問題になりました。 そこでこのためのオプションkube-reservedとsystem-reservedをサクッと設定して平和に… でも余分に割り振ったらリソースもったいないし、少なすぎたらやる意味ないし、適切な値を… なんて考えてたら完全理解に時間がかかったのでざくざくまとめておきます。 参考ドキュメント https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/node-all
はじめに おはようございます、加藤です。皆さんはKubernetesを壊した事がありますか?私は今月2回ほど、破壊しました。 キャッチアップ中かつ、開発環境での話しなので、笑っていられますが、これが本番環境だったら恐ろしすぎますね。 唐突ですが、ここに本番環境では kubectl を使って操作しない事を誓います(ReadOnly権限の場合を除く)。 事件概要 先日、EKSにArgoCDをどうデプロイするか、設定をどうするか検証していた際に事件は発生しました。Kustomizeで、applyordeleteしたり、Namespaceのcreateordeleteを繰り返していました。その結果、タイミングの影響なのか以下のような奇妙な状況に陥りました。 Namespace: argocd は Terminating Applicationという名前の、CRD: demo-appが存在する 上記
IBM Cloud の Kubernetes サービスに 2019年7月で Red Hat OpenShift が加わった。このOpenShiftは、Red Hat がサブスクリプションでサポートするソフトウェアであり、Kubernetesの本来の機能に加えて、Red Hat の魅力的な機能が、たくさん追加されている。 その一端を知るために、IBM Cloud のOpenShift チュートリアルを実行しながら、KubernetesとOpenShiftの違いを確かめたメモである。 本メモは、OpenShift on IBM Cloud をデプロイした後に、oc login が成功して、ocコマンドが実行できる状態からの開始を想定している。oc login までの手順は、OpenShiftクラスタ管理画面のタブ「アクセス」に従ってセットアップできるので省略する。 バージョンの表示 最初にOp
オペレーター(Operator)は、約3年前にCoreOSから発表[11][12]され、人間のオペレーターの知識をコード化するといった構想が注目を浴びた、しかし、その実態の難解さが障壁であった。それから最近になって Red Hat社のOpenShift4の発表において、オペレーターの推進が前面に押し出され、今年初めには、さらに後押しするように、主要クラウドベンダーと協力してOperatorHub.io を推進することが発表[13]された。IBM Cloud でも Red Hatと統合とOpenShiftの推進に加えて、オペレーターを推進する姿勢が強くなっている。 これは、そもそもオペレーターとは?、その実態についての疑問、現在の目標達成レベルなどについて、調べた結果のメモである。この内容は、筆者が個人的に調べで、まとめた内容である、その中には誤りを含む可能性もあるので、ご留意いただきたい。
Jobとは 常駐するアプリケーションでなく、単発で実行して実行完了後はそのまま終了するような用途にはJobを使用する。 ここではJobで起動したPodがエラーで停止した場合も、自動再実行せずにそのまま終了させたい場合の設定についての調査とまとめ。 以下の環境で確認 Minikube v0.35.0 (Kubernetes v1.13.4) MiniShift v1.32.0 (OKD v3.11.0) ※ JobはrestartPolicyはNever前提とする 2019.04.02 精度について追記 TL;DR 以下の設定をspec直下に追加してJobを作成する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く