Kubernetes 1.12: SIG-CLI (kubectl) の変更内容 - Qiita
はじめに 1.11 に続き、今回も Kubernetes 1.12 における SIG-CLI の取り組みについてまとめています。 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md#sig-cli https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md#sig-cli-1 新たに追加されたコマンド なし 廃止予定のコマンド なし 廃止されたコマンド なし その他オプションの追加、削除などの変更は、https://github.com/superbrothers/kubectl-docs/compare/v1.11.0...v1.12.0 で確認できます。 SIG-CLI の主な取り組み SIG-CLI は、新しいプラ
helm template: Helm Chart をマニフェストファイルとして展開する - Qiita
概要 Helm はマニフェストファイルの集まりをパッケージとしてバージョンニングし管理できる Kubernetes のパッケージマネージャです。Helm は helm クライアントと tiller サーバの二つのコンポーネントから構成されており、Kubernetes クラスタ内で実行される tiller サーバが Helm のパッケージである Chart の管理、リリースを行ないます。 helm template は、Helm 1.7 で実装された helm クライアントのサブコマンドです。対象の Chart をマニフェスト形式で展開することができます。 $ helm template --help Render chart templates locally and display the output. This does not require Tiller. However, an
Kubernetes: kubectl にエイリアスを設定して生産性を上げよう - Qiita
はじめに Kubernetes なみなさん、日々どのくらい kubectl とタイピングしてますか？ OpenShift 方面の方はニヤニヤしているかもしれませんが、kubectl はそこそこタイプ数が多いです。このコストを最小化することで日々の生産性を向上しましょう。 kubectl にエイリアスを設定する エイリアスは k に設定します。これで oc に勝てます。 これだけなのですが、もちろん補完も設定しなければなりません。補完については kubectl completion: Bash/Zsh 向けの kubectl のシェル自動補完 に詳しく書いたのでそちらを参照してもらうとして、補完が有効にならないととてもじゃないですが快適な Kubernetes 生活は過ごせません。あらゆるところでコピペが必要になります。しかし残念ながらこれまではエイリアスに対して補完を設定しても正常に動作し
[Node.js] istanbul でカバレッジが出力されないとき - Qiita
process.on("exit") で書き込み処理が実行されるので、テストにおいて process.removeListeners() でハンドラを削除してしまっていると出力されない。 ハンドラを削除する必要がある場合は、process.listeners("exit") で事前にハンドラを退避し、事後に設定し直すことで対応できる。下記は istanbul + mocha での場合。 var exitHandlers; before(function () { exitHandlers = process.listeners("exit"); }); after(function () { exitHandlers.forEach(function (handler) { process.on("exit", handler); }); }); Register as a new use
![[Node.js] istanbul でカバレッジが出力されないとき - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/bde4054c63e622e9ad8dfaf2d9021cd985892283/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCTm9kZS5qcyU1RCUyMGlzdGFuYnVsJTIwJUUzJTgxJUE3JUUzJTgyJUFCJUUzJTgzJTkwJUUzJTgzJUFDJUUzJTgzJTgzJUUzJTgyJUI4JUUzJTgxJThDJUU1JTg3JUJBJUU1JThBJTlCJUUzJTgxJTk1JUUzJTgyJThDJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgxJUE4JUUzJTgxJThEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDFmNDNhMzdiMTU1Y2IyZGMyMTU1M2RmOGIwMGQ3OA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc3VwZXJicm90aGVycyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YWE5MDI2OTZhZmEzNWEyNTBlNTQ5NjYyYzJlOGI5Mzk%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D1941c2c4d59457f99f75040a303939e8)
zlabjp/kubernetes-resource: Kubernetes を操作する Concourse リソース - Qiita
概要 ゼットラボではいくつかの CI/CD ツールを利用していますが、その中の一つが Concourse です。Concourse はパイプラインベースの CI/CD ツールで Pivotal により開発されています。Concourse から Kubernetes にアプリケーションをデプロイするための Concourse リソースに我々の要件を満たすものが存在しなかったため、新たに開発し OSS (MIT License) として公開しています。 zlabjp/kubernetes-resource: A Concourse resource for controlling the Kubernetes cluster Kubernetes にどのようにアプリケーションをデプロイするか Kubernetes にアプリケーションをデプロイするには Kubernetes を操作するための C
Kubernetes: Admission Control (1.8) - Qiita
はじめに Admission Controlとは Admission ControlとはKubernetesのAPI Serverのリクエスト制御の機能です。APIリクエストに対して認証、認可を行ったあとのフェーズで、別途そのリクエストを受け入れるか制御を行います。また場合によって、リクエストの変更や別の操作を行います。 プラグイン形式で複数の制御の方法が用意されており、APIの起動オプション--admission-controlで有効にしたいものをカンマ区切りで指定します。 Kubernetes: Admission Controlとは何か 上記エントリは 1.2 時点でのプラグインを紹介していますが、ここでは 1.2 から 1.8 までに新たに追加されたプラグインについて記載します。 プラグイン一覧 DefaultStorageClass DefaultTolerationSecond
kubectl completion: Bash/Zsh 向けの kubectl のシェル自動補完 - Qiita
はじめに Kubernetes のコマンドラインツールである kubectl (cube control1) には Bash/Zsh 向けの shell autocompletion が実装されています。シェル自動補完を利用すればサブコマンドや Pod 名を途中まで入力すれば後は動的に値を候補から補完してくれます。もうリソース名をコピペする必要はありません。 シェル補完を有効にする Bash を使用していれば次のコマンドを実行して .bashrc に一行追記します。これで次からのシェルの実行で自動的にシェル補完が有効になります。
Kubernetes: 詳解 Pods の終了 - Qiita
はじめに Pods は Kubernetes の中でもっとも重要なリソースです。複数のコンテナとボリュームの組み合わせで Kubernetes におけるスケールの最小単位であり、アプリケーションコンテナは必ず Pods としてデプロイされます。 ここでは Pods の終了の流れについて詳しく扱います。Deployments の更新などで新しいバージョンのアプリケーションをデプロイするとき、既存の Pods は終了されます。このとき正しく Pods の終了処理を準備できていないと、ユーザのリクエストが正しく処理されずエラーが出力されているかもしれません。ワンオフなジョブと異なり、サーバとしてデプロイされる Pods はそれと比べて比較的寿命は長く、更新の頻度は少ないかもしれません。しかしサービスの価値をいち早くユーザに届けるに頻繁なデプロイは欠かせません。よりデプロイの頻度が高くなるほど P
Kubernetes v1.8: 主な変更点 (Major Themes) - Qiita
このエントリは、Kubernetes v1.8 CHANGELOG から主な変更点 (Major Themes) をまとめています。その他の項目は下記リンク先を参照してください。 Kubernetes v1.8: 主な変更点 (Major Themes) Kubernetes v1.8: Before Upgrading Kubernetes v1.8: 既知の問題 (Known Issues) Kubernetes v1.8: Deprecations Kubernetes は、分野ごとに Special Interest Groups (SIGs) として組織されたコミュニティメンバーによって開発されており、v1.8 の CHANGELOG から SIG 毎にそのバージョンで取り組んだ事柄がそれぞれ記載されるようになった。 SIG API Machinery リスト取得の小さなチャンク
Kubernetes v1.7: Action Required Before Upgrading - Qiita
このエントリは Kubernetes v1.7 CHANGELOG の Action Required Before Upgrading をまとめています。 https://github.com/kubernetes/kubernetes/blob/3f0141edd52ab6fd7b6fe473ecceb480faf12079/CHANGELOG.md#action-required-before-upgrading その他の項目は下記を参照してください。 Kubernetes v1.7: Major Themes Kubernetes v1.7: Action Required Before Upgrading Kubernetes v1.7: Deprecations Kubernetes v1.7: Notable Features 抜粋 Network net.beta.kube
Kubernetes v1.7: Deprecations - Qiita
このエントリは Kubernetes v1.7 CHANGELOG の Deprecations をまとめています。 https://github.com/kubernetes/kubernetes/blob/3f0141edd52ab6fd7b6fe473ecceb480faf12079/CHANGELOG.md#deprecations その他の項目は下記を参照してください。 Kubernetes v1.7: Major Themes Kubernetes v1.7: Action Required Before Upgrading Kubernetes v1.7: Deprecations Kubernetes v1.7: Notable Features 抜粋 Cluster provisioning scripts cluster/ubuntu: 廃止およびメンテナンスされていな
Kubernetes の小技 2016 - Qiita
function kubectl() { command kubectl \ --context="$KUBECTL_CONTEXT" \ --namespace="$KUBECTL_NAMESPACE" \ --user="$KUBECTL_USER" \ --server="$KUBECTL_SERVER" \ "$@" } kubectl のアクセス先のサーバやネームスペース、ユーザ、それらの組み合わせであるコンテキストは kubeconfig ファイルを使い指定しますが、一時的に設定を切り替えたいときには kubectl に用意されている --context, --namespace などのオプションを使うことができます。ただこれらのオプションは都度指定する必要があるため手間です。 上記の関数を使うことで、それぞれのオプションを環境変数によって指定することができるようになります。環
Minikube で快適に Ingress を利用する - Qiita
TL;DR minikube addons enable ingress で Minikube で簡単に Ingress を使いはじめることができる ローカルのネームサーバで Ingress に設定したホスト名を名前解決させてより快適に利用する Minikube 標準の Ingress Controller の代わりに nghttpx-ingress-controller を使うのも簡単、そのときカスタム Cluster Add-on を使うとより快適に利用できる はじめに プロダクションにおいて Ingress を利用しているならローカルの Minikube においても Ingress を利用して動作を検証したい。Minikube は、ローカルにシングルノード構成の Kubernetes クラスタを簡単に構築できるツールである。 Ingress を使うには、作成されている Ingress
kubectl で OpenID Connect ID トークンをリフレッシュする - Qiita
はじめに Kubernetes クラスタの認証に OpenID Connect ID トークンを利用するとき、kubectl からクラスタを操作するには、ID トークンを kubeconfig ファイルのユーザエントリ token として設定します。 このとき、設定した ID トークンの有効期限が切れると認証に失敗してしまいます。一般的に ID トークンの有効期限が切れたら、リフレッシュトークンを使い ID トークンをリフレッシュする必要があり、ユーザエントリで token を使っているとリフレッシュした ID トークンを改めて kubeconfig ファイルに設定し直す必要がありました。 この問題は、kubeconfig ファイルのユーザエントリに token ではなく、OpenID Connect のトークンリフレッシュのフローを実行してくれる auth-provider=oidc を
Google Container Engine で新しいノードにダウンタイムゼロで移行する - Qiita
先日リリースしたアプリケーションが CPU 使ってなくてスカスカだったので、ノードのマシンタイプを n1-standard から f1-micro に変えました。今後もときどき行うことになりそうなので手順を残します。このアプリケーションはストレージを全く使っていないため、ストレージを利用している場合にはこの手順ではうまくいかないかもしれません。注意してください。 マシンタイプの違うノードにダウンタイムゼロで移行する $ gcloud container node-pools create f1-micro-pool --machine-type f1-micro --num-nodes=2 --zone=asia-east1-c まず移行先のノードを作成するためにノードプールを作成します。ここでマシンタイプやゾーン、初期のノード数などを指定します。ディスクサイズもここで指定できます。 ノー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
docker-machine で localhost でポートを公開する - Qiita