Kubernetesのキャッシュネームサーバとリゾルバ | IIJ Engineers Blog
ただ、サーチリストがこうなっているのは利便性のためだけではなく、もっと切実な理由があります。 サーチリストとndots DNSの一般的な名前解決のルールとして、こんな風に覚えている方もいるかもしれません。 名前にピリオドが含まれていたら、FQDNとみなしてサーチリストを参照せずに名前解決を行う 名前にピリオドが含まれていなければ、サーチリストのドメインを末尾に連結して名前解決する 例えば、こんな具合です。 $ ping myhost # ピリオドが含まれていないため、myhost.example.comが名前解決される PING myhost.example.com (192.168.0.1) 56(84) バイトのデータ 64 バイト応答 送信元 myhost.example.com (192.168.0.1): icmp_seq=1 ttl=57 時間=12.4ミリ秒 $ ping w
Customizing DNS Service
This page explains how to configure your DNS Pod(s) and customize the DNS resolution process in your cluster. Before you beginYou need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a
GCPとkubelet: クラスタ管理の核心を理解する｜noise
Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するオープンソースプラットフォームです。その中心に位置するのがkubeletというコンポーネントで、これは各ノードで動作し、Pod内のコンテナが正しく動作していることを保証します。このコラムでは、Google Cloud Platform（GCP）上で動作するKubernetesのkubeletについて詳しく解説します。 kubeletとは何か？kubeletは、Kubernetesクラスタ内の各ノードで動作するエージェントです。kubeletの主な役割は、PodSpecs（Podの仕様）を取得し、それに基づいてPod内のコンテナが正常に動作していることを確認することです。PodSpecsはさまざまなメカニズムを通じて提供されますが、kubeletはKubernetesによって作成
Kubernetes内のアプリログをSplunkに送る
はじめに Kubernetesはロギングもホストとは諸々違います。 ただ、一つ変わらないことはSplunkに送ればなんでもできるということです。 ということでKubernetesのコンテナログの送信方法をまとめました。 使用するエージェント Splunk OpenTelemetry Collector for Kubernetes（以下、Splunk Otel）を使います。 これはOpenTelemetry CollectorをKubernetes環境に使いやすくチューニング、機能追加したものです。 Helm Chartが用意されており様々な設定を自動化できます。可能な設定について詳細はこちら。 HEC準備 Splunk OtelではSplunkへはHECで送信するため、先に準備しておきます。 ヘッダーメニューから 設定 > データ入力 HTTPイベントコレクターの「新規追加」をクリック
Pod Lifecycle
This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting in the Pending phase, moving through Running if at least one of its primary containers starts OK, and then through either the Succeeded or Failed phases depending on whether any container in the Pod terminated in failure. Whilst a Pod is running, the kubelet is able to restart containers to handle some kind of fa
[Kubernetes]Jobの動作を確認する 3 - Qiita
なお、前回説明した「spec.backoffLimit」パラメータの値を0にしていると、一回障害が起きた時点でJobの終了条件を満たしてしまいますので、リトライさせる場合には、「spec.backoffLimit」の値を1以上にする必要があります。 Never まずはNeverの動作を確認してみます。 これは前回でも設定していましたので、同じ動作になります。 こちらのyamlファイルで動作を確認します。 apiVersion: batch/v1 kind: Job metadata: name: sample-job-back spec: completions: 5 parallelism: 1 backoffLimit: 3 template: spec: containers: - name: sample-job1 image: centos:latest command: ["s
![[Kubernetes]Jobの動作を確認する 3 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/23a09f251944419cac1bb5971c5f6f750716ec13/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCS3ViZXJuZXRlcyU1REpvYiVFMyU4MSVBRSVFNSU4QiU5NSVFNCVCRCU5QyVFMyU4MiU5MiVFNyVBMiVCQSVFOCVBQSU4RCVFMyU4MSU5OSVFMyU4MiU4QiUyMDMmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTc1MmZhMmU2N2YzZDBkZjAyMzM1NTRkOWZkNjRhNjhk%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBkaW5ndGlhbmhvbmdqaWUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTE5OTkxMzEyODZmOTMxMTZjYjNjNWQzZWFlZWQ1MjRj%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db20fdb0ad3b707634ab39a495ca15091)
[Kubernetes] CronJobで .spec.suspend を TRUE に指定するときに注意すべきこと - Qiita
はじめに CronJobを一時的に止めておきたかったので .spec.suspend を使ってみたのですが、自分的に予想外の動きをしてしまったので、対処方法をまとめておきます。 この .spec.suspend の注意点を見逃すと、CronJobが一時的に停止した状態からJobを生成できなくなります。 対処方法までまとめましたので、是非最後まで読んでいただければと思います。 本記事は、 1.22.12-gke.300 で動作確認しました。 やりたいこと 1分ごとに Hello! と言ってくれるCronJobを作成しました。社交的なCronJobですね。 apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: schedule: "* * * * *" jobTemplate: spec: template: spec:
![[Kubernetes] CronJobで .spec.suspend を TRUE に指定するときに注意すべきこと - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/cc5f74178fe3cd3bd145a84e447be7b1a5db9338/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCS3ViZXJuZXRlcyU1RCUyMENyb25Kb2IlRTMlODElQTclMjAuc3BlYy5zdXNwZW5kJTIwJUUzJTgyJTkyJTIwVFJVRSUyMCVFMyU4MSVBQiVFNiU4QyU4NyVFNSVBRSU5QSVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSVBOCVFMyU4MSU4RCVFMyU4MSVBQiVFNiVCMyVBOCVFNiU4NCU4RiVFMyU4MSU5OSVFMyU4MSVCOSVFMyU4MSU4RCVFMyU4MSU5MyVFMyU4MSVBOCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NjlmYTk0NmQ3Y2Q1NTIxOGY5Nzc2YmJhMGQyZTUxMzg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzZWtpbmV0JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02MjU3NjQ3MzU3OWU3NjA4NjE1ZTNkYTc2NzMxNmFhZA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gTlRU44OH44O844K_5YWI56uv5oqA6KGT%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dccdfe8da520dc52b1a3e12c2e302b548)
Kubernetes: 複数の Node を安全に停止する (kubectl drain + PodDisruptionBudget) - Qiita
Kubernetes: 複数の Node を安全に停止する (kubectl drain + PodDisruptionBudget)kubernetes OS のアップデートやスケールダウンなどで複数の Node を安全に停止したい場合のメモです。この記事は Kubernetes 1.7.3 で確認した情報を元に記載しています。 TL;DR Node を停止するためにはkubectl drain コマンドを利用して停止準備を行います drain は Node を Pod のスケジュール対象から外し (unschedulable に設定) Node 上の Pod を退去させることで停止可能な状態にします しかし複数の Node を停止させる場合、アプリケーションの Pod が一つも動作していない状態 (ready な Pod が 0)がありえるので注意が必要です PodDisruption
Helm とは？をわかりやすく解説
Kubernetes でのアプリケーション開発は複雑です。どんなアプリケーションであっても、おそらく何百もの構成をインストールし、管理し、更新しなければなりません。 これに対し、Kubernetes のパッケージマネージャーである Helm には、 アプリケーションのクラスタへのデプロイに必要なすべてのコードとリソースが含まれ、アプリの配信を自動化します。 Helm は、Helm チャートと呼ばれるパッケージングフォーマットを使用してアプリケーションの配信を自動化することにより、このプロセスを単純化します。Yum が Red Hat® Enterprise Linux® の RPM パッケージを管理するのと同じように、helm は Kubernetes の Helm チャートを管理します。チャートは、コンテナ間の一貫性を維持しながら、アプリケーションの特定の要件がどのように満たされているか
Kubernetes "ジョブ" についての自習ノート - Qiita
この投稿は、Kubernetes（以下 k8s)のジョブについて、理解を深めるために、https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ を読み解いたもので、個人的な補足や、検証を含むものです。 k8sのジョブとは ジョブは1つまたは複数のポッドを作成し、指定された数のポッドが正常に終了することを保証します。 ポッドが正常に完了すると、ジョブは成功完了を管理します。 指定された数の正常な完了に達すると、ジョブ自体は完了です。 ジョブを削除すると、作成したポッドがクリーンアップされます。 簡単なケースでは、確実に1つのポッドを完了して実行するために、1つのジョブ・オブジェクトを作成します。 ジョブ・オブジェクトは、最初のポッドに障害が発生した場合やノードのハードウェア障害やノードの
EKS Cluster の消費 IP 数を減らす - YasuBlog
EKS Cluster を構築すると VPC 内の IP を大量に使うので、IP 数の削減方法について整理し検証しました。 1. EKS Cluster の ENI と IP アドレスの挙動 2. デフォルト設定の Cluster を構築した際の消費 IP 数 3. 消費 IP の削減方法 4. 検証 4.1. 設定方法 4.2. WARM_ENI_TARGET 4.3. MAX_ENI 4.4. WARM_IP_TARGET 4.5. MINIMUM_IP_TARGET 4.6. どの環境変数を使用するか 5. まとめ 6. 参考 1. EKS Cluster の ENI と IP アドレスの挙動 EKS のデフォルト CNI である Amazon VPC CNI の ENI と IP アドレスの挙動は以下になります。 コントロールプレーン（Master） ENI が 2 個付く ENI
Amazon EKS ワーカーノードが確保するIPアドレスを減らす
はじめに EKSワーカーノードが、VPCサブネットのプライベートIPアドレスを大量に消費してしまい、プライベートIPアドレスが枯渇しまう問題が発生した。 暫定的な対策を取った記録をまとめる。 やったこと 最初に暫定対策を書いておく。 デフォルトで入っている aws-node プラグインの設定値を変更して、余分に確保されていたプライベートIPアドレスを開放した。 下記のコマンドを実行すると、aws-node が全て再起動して設定が反映される。 kubectl -n kube-system set env daemonset aws-node WARM_ENI_TARGET- kubectl -n kube-system set env daemonset aws-node MINIMUM_IP_TARGET=20 kubectl -n kube-system set env daemonse
サンプルアプリケーションをデプロイする - Amazon EKS
前提条件 既存の少なくとも 1 つのノードがある Kubernetes クラスター。既存の Amazon EKS クラスターがない場合は、Amazon EKS の使用開始 のガイドの 1 つを使用して Amazon EKS クラスターをデプロイできます。Windows アプリケーションをデプロイする場合は、クラスターと少なくとも 1 つの Amazon EC2 Windows ノードで Windows サポート を有効にする必要があります。 コンピュータに Kubectl がインストールされている。詳細については、「kubectl のインストールまたは更新」を参照してください。 クラスターと通信できるように Kubectl が設定されている。詳細については、「Amazon EKS クラスターの kubeconfig ファイルを作成または更新する」を参照してください。 サンプルワークロードを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Observability and Cause Diagnosis of DNS Faults in Kubernetes Clusters
Utilising Warm pool with EKS to reduce Boot up time