ry's Tech blog

Cloud Native技術などについて書いていきます。

Kubenews #8

kubenews

2021-02-05

配信URL

https://youtu.be/QtHOLScNtXYyoutu.be

各タイトルを押していただくことで、実際の記事に飛びます。

スクリュードライバーとKubernetesを使用したデータベースのマイグレーション

Self-Service Velero Backups with Kyverno

veleroを使ってバックアップの準備をし、kyvernoのgenerate機能を用いてnirmata.io/auto-backup: enabledというlabelが付いたNamespaceが作成されたときに、VeleroのBackup Scheduleを作成するもの。

LWKD

kubenews #7

kubenews

2021-01-29

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

Kubernetes Cost Reporting using Kubecost

  • kubernetesの上で動かし、現在の使用状況からどれくらいのコストがかかりそうか、どれくらいのコストカットができそうかなどをみることができる。
  • 実際に見てもらいたいと思います。

Project Agumbe: Share Objects Across Namespaces in Kubernetes

  • Global ResourceというCRD オブジェクトを使って、Namespaceに依存するリソースの複製を他のNamespaceにつくるもの
  • コピー元をParent Object、コピーをChild Objectと呼ぶ。

【EKSWorkshop】EKSやkubernetes周辺を効率よく学ぶのにオススメなチュートリアル集

  • EKSを学んでいくためのチュートリアル
  • 一緒にやっていく人を大募集中なので、よければryにご連絡ください。
  • やりたいもの
    • Start the workshop
    • Deploy the Example Microservices
    • Autoscaling our Applications and Clusters
    • Using Spot Instances with EKS
    • Service Mesh With App Mesh

Kubenews #6

kubenews

2021-01-22

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

GCPSketchnote

GCPの様々なリソースについて絵を使って、動作やユースケースなどの説明してくれている。

CNCF Security Whitepaper Shows the Complexity of Securing Cloud Native Operations

  • Cloud Native Security Whitepaperというものがあるらしい。
  • CNCFは、クラウドネイティブ開発は、develop、destribute、deploy、runtimeの4つの異なるライフサイクルフェーズにモデリングする必要があると述べている。
    • Develop: アプリケーション作成段階
      • セキュリティはアプリケーションライフサイクルの早い段階で導入する必要がある。
      • セキュリティテストではコンプライアンス違反や設定ミスを即座に特定しよう。
      • 12 FactorAppなどの推奨デザインパターンに準拠しよう。
    • Destribute: CICDの段階
      • 開発者は、マルウェアを含んだimageをデプロイする可能性がある。
      • 脆弱性、マルウェア、および安全でないコーディングをコンスタントにスキャンする必要がある。
    • Deploy: Containerとして動かす段階
    • Runtime: 基盤に関して
      • 認可されたプロセスのみがコンテナ名前空間内で動作する
      • 不正なリソースアクセスを防ぐ -　敵対的なツールアクティビティを検出するために、ネットワーク監視を行う

What’s Your Kubernetes Maturity?

  • Kubernetes Maturity Modelというものをざっくりと解説した記事
    • Phase1: Prepare
      • Kubernetesが、ビジネス目標と技術目標の推進にどのように役立つか、コスト、および達成しようとしていることを検討
    • Phase2: Transform
      • 基礎的な知識や理解、マインドセットだったりエコシステムの変革を行う段階
      • 既存の技術をCloud Nativeな文脈から見ること、技術的負債を払拭してKubernetes内に持ち込まないこと
    • Phase3: Deploy
      • 実際にKubernetes上でApplicationを本番運用し始める。
      • CI / CDのセットアップ、開発者の権限付与、限定的な監視と可観測性の導入
    • Phase4: Build Confidence
      • 経験から自信をつける段階
    • Phase5: Improve Operation
    • Phase6: Measure & Control
      • この段階では、何を測定および追跡し、どのようにKubernetesを制御するかを理解すべく、より多くのデータ、インサイト、ツールによる情報を収集して処理する。
      • infrastructure as code and CI/CD driven processes
    • Phase7: Optimize and Auutomate

Kubenews #5

kubenews

2021-01-15

配信URL

https://youtu.be/8Y_aHyveDUYyoutu.be

各タイトルを押していただくことで、実際の記事に飛びます。

Kubernetes Storage Performance Comparison

  • GlusterFS, CEPH, Portworx, OpenEBS(cStor backend), OpenEBS MayaStor, Longhornの比較記事
  • 比較はAKS上で実施
  • 結果としては、Portworx と OpenEBS Mayastorがすごそう

KubernetesにおけるContainer Object Storage Interface (COSI)の概要

  • Object Storage用のCSI相当であるCOSIについての解説記事
  • BucketRequest (PVC)、Bucket (PV)、BucketClass (StorageClass)は分かった。
  • BucketAccessRequest、BucketAccess、BucketAccessClassあたりがいまいち。。。

Kubenews #4

kubenews

2020-12-18

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

Efficient Multi-Zone Networking with Topology Aware Routing

Topology Aware Routing of Services： topologyKeysを用いてトラフィックを細かく分割する方法

  • Kubernetes v1.17 alpha機能であり、影響範囲はPod-Pod間の通信
  • TopologyKeyにおいて、Nodeのlabelを設定することで、上から書かれている順番に応じて、優先的に指定Labelを持つNode上で動くPodに通信が流れるように設定できる。
    • 例えばマルチAZ構成において、クライアントと同一ノードまたは同一AZのようなネットワーク的に近いエンドポイントにトラフィックが優先的にルーティングされるように指定できる。
  • 1Serviceに複数Endpointがひも付く構成になる。

以下のマニフェストでは、 1. kubernetes.io/hostnameより、同一Node 2. topology.kubernetes.io/zoneより、同一Zone 3. topology.kubernetes.io/regionより、同一region 4. *より、その他全て

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  topologyKeys:
    - "kubernetes.io/hostname"
    - "topology.kubernetes.io/zone"
    - "topology.kubernetes.io/region"
    - "*"

OPA The Easy Way

無料オンライントレーニングと[Styra DAS Free]（https://www.styra.com/pricing)の宣伝。

[VScode OPA Plugin]（https://marketplace.visualstudio.com/items?itemName=tsandall.opa)もあるらしい。

  • Styra DAS Freeへのアクセス
  • 自分のk8s clusterの登録
  • 各種ルールの作成
  • ルールのテスト
  • etc

自分的に一番嬉しいのが、AddmissionReviewの取得ができるらしい！

Automating Volume Expansion Management

Persistent Volumeを用いる際は、PrometheusにこのAlertを入れたほうがいい。

    - alert: "Storage Saturation"
      labels:
        severity: critical
      annotations:
        summary: Storage usage over 75%
        persistentvolumeclaim: 
        namespace: 
      expr: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.75
      for: 1m
 ```

という前置きの元、PVの拡張を自動化するソリューションとして、volume-expander-operatorに関する紹介が始まる。

- 監視したいPVCのannotationに`volume-expander-operator.redhat-cop.io/autoexpand: “true”`を設定が必要。
  - Once enabled, the volume-expander-operator will start polling the platform Prometheus instance that is part of OpenShift Monitoringとあり、OpenShiftでしかできなそう？？
- `kubelet_volume_stats_used_bytes`と`kubelet_volume_stats_capacity_bytes`の2つのメトリックより判断。
- その他設定するannotaionは以下
  - volume-expander-operator.redhat-c<200b><200b>op.io/expand-threshold-percent: ボリュームの拡張をトリガーする閾値
  - volume-expander-operator.redhat-c<200b><200b>op.io/expand-by-percent: 拡張される既存ボリュームのサイズに基づくパーセンテージ
  - volume-expander-operator.redhat-c<200b><200b>op.io/expand-up-to: ボリュームの上限
  - volume-expander-operator.redhat-c<200b><200b>op.io/polling-frequency：　ポーリングする頻度

参考manifest

kind: PersistentVolumeClaim apiVersion: v1 metadata: annotations: volume-expander-operator.redhat-cop.io/autoexpand: 'true' volume-expander-operator.redhat-cop.io/expand-threshold-percent: "85" volume-expander-operator.redhat-cop.io/expand-by-percent: "20" volume-expander-operator.redhat-cop.io/polling-frequency: "1m" volume-expander-operator.redhat-cop.io/expand-up-to: "20Gi" name: to-be-expanded spec: accessModes: - ReadWriteOnce resources: requests: storage: "1Gi"

Kubenews #3

kubenews

2020-12-11

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

With the release of GKE node version 1.19, the Container-Optimized OS with Docker (cos) variant is deprecated

Amazon EMR on Amazon Elastic Kubernetes Service (EKS)

  • Amazon EMR: big data platform for processing vast amounts of data using open source tools such as Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi, and Presto.
  • AWS News Blog
  • さまざまなEC2インスタンスタイプでパフォーマンスを最適化して、価格とパフォーマンスの要件を満たしていたものを、EKS上で動かすことでリソースを共有したり、管理を統合できたりなどのメリットがある。
  • 現在EC2で使用しているものと同じEMR機能をすべてEKSで利用できる。

Kubernetes CRDs = Huge Pain In Multi-Tenant Clusters

Kubernetesにおけるマルチテナンシーとは、複数のユーザー、アプリケーション、またはワークロードがいわゆるテナントを形成し、
共有クラスター内で互いに共存しているシステムアーキテクチャです。
マルチテナントを管理する際、以下のことが重要である。

・侵害されたテナントが残りのユーザーまたはワークロードに与える影響を最小限に抑えるために、テナント間に適切なレベルの分離を実装する必要がある。
・各テナントがタスクを完了するために必要なものにアクセスできるよう、コンピューティング、ネットワーキング、
  およびその他のリソースがクラスター内のすべてのテナント間で公平に共有されるようにする必要がある。

この２つを満たすために、テナントには独自のCRDおよびRBACルールを追加または管理することを許可されていないというケースが多い。

マルチテナントクラスターでCRDを使用する際の問題点
・クラスター内の他のユーザーが使用している他のリソースと競合しないようにする
・マルチテナントクラスターにセキュリティの脆弱性をもたらす可能性がある
  (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11247)
・CRDが互換性のない方法で変更または変更された場合、クラスター全体で問題が発生する可能性がある。
・マルチテナント設定でCRDを使用すると、管理上の責任と課題がさらに追加される。

解決策

・回避できる場合はCRDを使用しない。
・個別のクラスターまたは仮想クラスターを検討する。
  (https://loft.sh/blog/introduction-into-virtual-clusters-in-kubernetes/)

Graceful shutdown in Kubernetes is not always trivial

  • FLANT blog
  • nginxとPHP-FPMにおける、Graceful Shutdownの違いについて簡単に説明している。
  • 一例として以下のことが書かれていた。
    • nginxでは、preStopに書くものは、nginx -s quit　だけで良い。
    • PHP-FPMでは、プロセスを止めるのにsignalsで sigtermではなくsigquitを送る必要があった。
  • 結論としては、
    • Application側
      • 数秒待ってから、新しい接続の受け入れを停止する必要があります。
      • すべての要求が完了するまで待機し、アイドル状態のキープアライブ接続をすべて閉じる。
      • 独自のプロセスを終了する必要があります。
    • k8s側
      • sleepなどの特定の遅延を実行するpreStopを追加します。
      • 負荷試験などによって段階的にバックエンド構成を分析して、止める際に必要なparameterを導き出しましょう。

Kubenews #2

kubenews

2020-12-04

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

AWS、オンプレミス向けコンテナ基盤ソフトウェア「Amazon ECS Anywhere」「Amazon EKS Anywhere」発表

1.20からDockerが非推奨になる理由