運び屋 (A carrier(forwarder) changed his career to an engineer)

Network / Cloud Native / Kubernetes / コンテナー / SRE / DevOps

SRE / DevOps / Kubernetes Weekly Reportまとめ#69(2021/5/23~5/28)

SRE DevOps Kubernetes WeeklyReport 週刊 英文技術記事まとめ

The English Version of this blog is here.

この記事は2021/5/23~2021/5/28発行の下記3つのWeekly Reportを読み、備忘録兼リンク集として残しているものです。

なるべく情報を早く届けたい/共有したいので、ブログのリンクを確認次第、先行公開しています。自身のコメントは随時追加しています。

  • 誰かの情報源や検索工数削減などになれば幸いです。
DEVOPS WEEKLY ISSUE #543 May 23rd, 2021
SRE Weekly Issue #271 May 23rd, 2021
KubeWeekly #263 May 28th, 2021
  • この記事を読んで疑問点や不明点があれば、URLから本文をご確認の上、ご指摘頂ければ幸いです。
  • 理解が浅いジャンルも、とにかくコメントする様にしていますので、私の勘違いや説明不足による誤解も多々あろうかと思います。
  • 情報量が多いので文字とリンクだけに絞っております。
  • 各レポートで取り上げられている記事には2020年以前のものもあり、必ずしも最新のものという訳ではない様です。

DEVOPS WEEKLY ISSUE #543 May 23rd, 2021

News

A detailed case study focused on a large infrastructure architecture effort moving from managing virtual machines to Kubernetes.
  • タイトルは「Using Kubernetes to rethink your system architecture and ease technical debt」。
  • タイトルに沿ってシステムを再構築しようとするときに直面する課題、システムが成長するにつれて直面する重荷、そしていかに何もしないこと自体が問題を引き起こし得るかを解説している。
An important post on the risks with the AWS “free” tier when it comes to learning and unexpected bills. This can apply to other developer-focused metered services as well.
  • タイトルは「Please fix the AWS Free Tier before somebody gets hurt」。
  • AWSの無料枠の問題点、予期しない多額の請求についての問題点を解説している。
A post on adopting service mesh that’s also a post on the risks inherent in adopting early stage technologies, in this case looking at dropping Istio and moving to Linkerd.
  • タイトルは「Service Mesh Wars, Goodbye Istio」。
  • 上記のEditorのコメントとタイトルにあるように、ほぼ 2 年間本番環境で Istio を使用した後にLinkerdに移行した話を、サービス メッシュ(SMI、CNCFとの関係など)の現状に触れて解説している。
Some observations on the imbalance in knowledge between vendors and buyers and the importance of market forces in solving some of the security challenges that are ever more visible.
  • タイトルは「Fix a broken market, and we can resolve so many cybersecurity issues」。
  • サイバーセキュリティー業界として、サイバーセキュリティー製品とサービスの有効性を定義および測定して、サイバーセキュリティーリスクとその管理方法に関する意思決定を改善するための新しいモデルを必要としていることを説いている。
New features in Kubernetes often lead to interesting user tooling a little later. This post looks at EphemeralContainers and the kubectl debug tool for debugging running pods.
Another pod on debugging Kubernetes, this time looking at pod status and in particular looking at debugging pending pods with the scheduler.
  • タイトルは「How to debug Kubernetes Pending pods and scheduling failures」。
  • 以下の理由でスケジュールの取得に失敗したPending状態のPodをデバッグするさまざまな方法を解説している。
    • Node-based scheduling constraints, including readiness and taints
    • Pods' requested resources exceeding allocatable capacity
    • PersistentVolume-related issues
    • Pod affinity or anti-affinity rules
    • Rolling update deployment settings
A pair of posts looking into garbage collection in Java and how to monitor its impact on your applications.
  • 2本の記事のセット。上記のEditorコメント通り、JavaのGCとアプリへの影響の監視方法を解説している。
  • 上記1本目のタイトルは「Understanding Java Garbage Collection Logging: What Are GC Logs and How to Analyze Them」。
  • 2本目のタイトルは「Best Java GC Log Analyzers: Top Analysis Tools You Need to Know in 2021」。以下7つのツールを紹介している。
    1. Sematext Logs
    2. GCViewer
    3. GCPlot
    4. IBM Garbage Collection and Memory Visualizer
    5. GCEasy
    6. Garbagecat
    7. Solarwinds Loggly

Tools

Batect is a tool for defining repeatable tasks to aid local development. Running builds, executing tests, running deployments, spinning up dependent services, etc.
  • 上記の通り、1つ以上のDockerコンテナーに関して開発タスク(ビルド、実行、テスト、リンティングなど)を定義し、それらのタスクをどこでも迅速かつ一貫して実行し、チームと簡単に共有するツール「Batect」のWebページ。
  • GitHubページはこちら。

SRE Weekly Issue #271 May 23rd, 2021

Articles

Naming names in incident writeups

Should you keep things anonymous (“an engineer”), or should you say exactly who did what? Here’s a solid argument for the latter.

Lorin Hochstein

  • 筆者がインシデントレポートの関係者を匿名で書くのではなく、関係者全員の名前を明示的に記載している理由を解説している記事。
  • 以下の説明部分が納得感高かった。
    • The reason I take the opposite approach of naming names is that I want to normalize the fact that incidents are aspects of the system, not the individuals. I feel like providing anonymity implicitly sends the signal that “the names are omitted to protect the guilty.”
    • My strategy in doing these writeups is to lean as heavily as I can into demonstrating to the reader that all actions taken by the engineers involved were reasonable in the moment. I want them to read the writeup and think, “This could have been me!”. I want to try to get the organization to a point where there is no shame in contributing to an incident, it’s an inevitable aspect of the work that we do.
How Systems Complexity Reduces Uptime

This article explores the downsides to a design composed of independent parts such as with microservices.

Ephraim Baron

  • 上記のEditorのコメント、タイトルの内容を解説している。
  • Key Takeawaysは以下。
    1. Design for component failure and to minimize its impact.
    2. Make components decoupled and asynchronous whenever possible so that loss of one 1. component does not cascade to others.
    3. Make critical components redundant and automatically scalable.
    4. Avoid stateful components whenever possible.
    5. Understand service interdependencies and failure modes.
    6. Eliminate unnecessary complexity (KISS).
User Simulation for Rapid Outage Mitigation

Uber designed a tool they call Blackbox to perform simulated user requests and measure availability. I was struck by the candid discussion of complexity — no one person can understand how all of Uber’s microservices go together.

Carissa Blossom — Uber

  • 本番環境の問題を特定するために Uber社が開発した監視サービスと、コンポーザブル統合テストを活用してmitigationまでの時間を半分に短縮した方法を解説している動画と、書き起こし。
Nobl9 Makes SLO Specification Open Source

They’ve made a YAML specification and validator for expressing SLOs in a machine-readable format.

Mike Vizard — Devops.com

  • SLOconfでNobl9社が発表した、ITチームがSLOを達成できるようにするために作成したプラットフォームが、オープン ソースの Apacheライセンスで「OpenSLO」として利用可能になったことを紹介している。
  • GitHubページはこちら。
  • 「SLO-as-code」の採用が進むのか、今後の動きが気になります。
What is Observability

A new spin: this one makes the distinction between “experimental tools” that affect the state of the system, and “observability tools” that are read-only.

Brendan Gregg

  • 上記のEditorのコメント同様、私も「experimental tools」と「observability tools」の区別が印象に残った。
The Incident Review: 4 Odd Incidents Caused by Animals

“Contributing factors: moose and squirrel.”

JJ Tang — Rootly

  • タイトル通り、動物が犯人である以下4 つのインシデントと、SRE がそれらから学べることを解説している。
    • Beavers break the Internet
    • Google cowed by cows
    • Squirrel power
    • Birds and planes: A dangerous combo
When Debuggers Lie

Every once in a while, I need to pull out gdb. In times like those, it’s useful to have this kind of thing floating around in the back of my mind.

Brendon Scheinman — okcupid

  • タイトルの問題の原因となったコードの簡略化されたバージョンを利用して解説している。

Outages

上記各社の障害情報

KubeWeekly #263 May 28th, 2021

The Headlines

Editor’s pick of the highlights from the past week.

How to bridge the gender gap in the tech sector

Yahoo Finance

Priyanka Sharma, Cloud Native Computing Foundation General Manager joined Yahoo Finance to discuss how to tackle the gender gap issue in the tech sector. Watch the interview here.

  • 上記内容の約6分間のインタビュー動画と書き起こし。
  • Gender Gap以外にも、継続的に取り組んでいるGenderに限らないDiversityに対するポジティブなメッセージを受け取れた。
  • 個人的には、Gapはあくまで取り組みを行うために有効な指標であり、比率が同一になることが理想ではないと考えています(もちろん環境や条件次第で偶然同一になることもあるでしょう)。「臨んだポジションに必要や業務遂行能力などが伴えば誰でもそこにチャレンジできる」「必要な支援が得られる」「能力を発揮できる」という状態が重要だと考えています。

ICYMI: CNCF online programs this week

A weekly summary of CNCF online programs from this week.

Universal Crossplane
  • Upbound社のUniversal Crossplane (UXP)ローンチに伴い、以下を解説している約1時間のセッション。
    • What is required to become a conformant distribution or provider
    • What organizations are already pursuing these goals
    • How UXP enables users to easily upgrade from upstream Crossplane to a production-ready distribution backed by the creators of the project
Containing your microservice sprawl
  • マイクロサービスの無秩序な増加による以下3つのチャレンジについて触れ、すべてのクラスターでのマイクロサービス管理とバージョニングの重要性を解説している約30分のセッション。
    1. Lack of organization.
    2. Ambiguous service ownership and profile.
    3. Reactive approach - lack of visibility.
Defense strategy against Kubernetes attack TTPs
  • タイトルに沿って以下4つを解説している約30分のセッション。
    • Multiple Threat actors attacking Kubernetes attack surface
    • Latest Tactics, Techniques and procedures(TTPs) used by each actor
    • Detection and mitigation for TTPs
    • Best practices to secure Kubernetes cluster
  • タイトルにあるTTPsは上記の通りTactics、Techniques、Proceduresの略。
Elevating Developer Experience with Cloud Native Tools
  • 企業がCNCFプロジェクトを活用して社内の開発者の経験をレベルアップし、最高の人材を採用して維持するだけでなく、SDLC(Software Development Life Cycle)内に存在する摩擦を減らすための主要な方法を解説している。

The Technical

Tutorials, tools, and more that take you on a deep dive into the code.

The Level Up Hour (E35): Podman v3 and docker-compose

Langdon White and Chris Short, Red Hat

  • podmanをバックエンドとして使用してdocker-compose を試している約70分のセッション動画。
Using files and devices in Podman rootless containers

Dan Walsh, Red Hat

  • コンテナ内からファイルやデバイスにアクセスする際の課題と解決法を解説している。
Visualize HAProxy metrics with InfluxDB

Jim O'Connell, HAProxy

  • HAProxy metricsをInfluxDB に表示するために必要なすべての手順を解説している。
gRPC load balancing in Rust

Helge Hoff, TrueLayer

  • TrueLayer社のWebページ上のエンジニアリングブログでのオープン ソース シリーズの最初の投稿。このシリーズでは同社のエンジニアリングチームが直面した課題について解説する。問題解決のために作成したコードは、OSS ライセンスの下でリリースされる。
  • 今回の記事では、Rust でgRPCの負荷分散の課題にどのように取り組んだかを解説している。
    • 今回利用されているツールのGitHubページは以下。
      • ginepro: ginepro provides client-side gRPC load-balancing out of the box by enriching tonic ‘s channel with periodic service discovery.
      • tonic: tonic is a gRPC over HTTP/2 implementation focused on high performance, interoperability, and flexibility. This library was created to have first class support of async/await and to act as a core building block for production systems written in Rust.
Using a Configmap as an OCI Image Cache

Daniel Mangum, Crossplane

  • タイトルの内容をCLIとマニフェストを見せながら解説している。各リソース、コマンド、引数などが文中で強調されていてポイントを掴みやすい。
Moving an application from VM to Kubernetes

Michael Heap, Kong

  • タイトル通り、アプリを VM からコンテナに移動し、Kubernetes でコンテナーを実行するという、一般的なシナリオについて解説している。

The Editorial

Articles, announcements, and morethatgive you a high-level overview of challenges and features.

Using Kubernetes to rethink your system architecture and ease technical debt

Chris Casey and James Lees, Pusher

  • 上記のDEVOPS WEEKLY ISSUE #543で取り上げているため、割愛。
How Adidas manages for scale

Alex Williams and B. Cameron Gain, The New Stack

  • タイトル通り、同社がどのように事業を拡大しているかについて語っているPodcastと、YouTube動画「Scaling DevOps and Resiliency on Kubernetes w/ Ignacio Alzorr & Rastko Vukasinovic」のポイントを書き起こして解説している。PodcastとYouTube動画がそれぞれWebページに埋め込まれている。
Evaluating your Supply Chain Security

CNCF Technical Advisory Group (TAG)

  • CNCF Technical Advisory Group (TAG)の文言を見て、SIGからTAGへの名称変更を思い出しました。GitHubeページはこちら。
  • 安全なサプライ チェーンを構築するための総合的なアプローチの提供を目的としたPaper「Software Supply Chain Security Best Practices」を紹介し、概説されたアプローチとして、以下「4 つのkey elements」や「A Framework for Supply Chain Evaluation」などに触れている。
    1. Trust
    2. Automation
    3. Clarity
    4. Mutual authentication
Red Hat and IBM Research launch the Konveyor project

Red Hat

Reminder: Take the CNCF Cloud Native Survey - Part 1 to share your thoughts on cloud, containers, and Kubernetes.
  • 先週案内した「CNCF Cloud Native Survey - Part 1 」のリマインダー。

Upcoming CNCF Online Programs

On-demand

Learn more about CNCF Online Programs

いかがでしたか？気になる記事や情報はありましたか？

私もまだ内容を咀嚼出来ていないものが多々ありますので、この備忘録兼リンク集を活用しながら理解を深めていきたいと思います。

では、また。

Bye now!!

Yoshiki Fujiwara