3 台の Raspberry Pi で始める自宅 Kubernetes クラスタの構築 - Qiita
はじめに 最近 Raspberry Pi を3台購入し、自宅に Kubernetes クラスタを構築しました。 この記事ではその体験記を共有します。 また、自宅 k8s を構築する際に参考になる記事になる事も目指しています。 モチベーション 仕事で GCP 上で Kubernetes を使ったので、個人で Kubernetes クラスタを構築してさらに学習を深めたいと思いました。 実務ではクラウドサービスを使いますが、維持費が高額です。一日システムを立ち上げておくだけで数千円、一ヶ月では数万円かかってしまいます。 minikube などを用いてローカル環境で Kubernetes を動かすこともできますが、シミュレーター上の動作になってしまうので、どうせなら実際の環境に近いものを構築したいと思いました。 そこで、Raspberry Pi を用いることで、実際の環境に近い学習環境を構築してみ
@Hiroki__IT が目の前にやってきて私にIstioのこと教えてくれた。- Istio in Action の読書感想文 - じゃあ、おうちで学べる
はじめに マイクロサービスアーキテクチャの台頭により、サービスメッシュ技術は現代のクラウドネイティブ環境において外せない選択肢の一つとなっています。 その理由は明確です。マイクロサービスに求められる非機能要件の多くは類似しており、これをアプリケーション側で個別に実装すると、開発者やインフラエンジニアの負担が増大するからです。 ここで登場するのがサービスメッシュです。サービスメッシュの採用により、これらの非機能要件をインフラ層で一元管理することが可能となり、アプリケーション開発者とインフラエンジニアの責務を明確に分離できます。つまり、各エンジニアが自身の専門領域にフォーカスできるのです。これは単なる効率化ではなく、イノベーションを加速させるためサービス開発する上での労苦をなくします。 そして、サービスメッシュの世界で圧倒的な存在感を放っているのがIstioです。その包括的な機能と広範な採用で
NetworkPolicyでtrafficを制御しよう - enechain Tech Blog
はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri
【Istio⛵️】Istioによって抽象化されるEnvoyのHTTPSリクエスト処理の仕組み - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Istioのサイドカーメッシュを題材にしたEnvoyの設定の抽象化について 様々なサービスメッシュツール (特に、Istio、Consul、Cilium、など) でも流用できるEnvoyの知識について この記事から得られる知識 01. はじめに 02. 様々なリソースによるEnvoy設定の抽象化 サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 03. istio-proxyコンテナによるHTTPS処理 Istioコントロールプレーンの仕組み サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 04. EnvoyによるHTTPS処理 Envoyの設定の種類 フィルター フィルターの一覧 フィルターチェーンの仕
Segment Routingを用いたKubernetes Podネットワーキングの実装 | CyberAgent Developers Blog
こんにちは、技術本部 プライベートクラウドグループの中西（@whywaita）です。 今回はCA Tech JOBの制度を用いてインターンに参加して頂いた上野さんからの寄稿記事です。 以下本文です。 みなさんはじめまして。 メディア事業部技術本部プライベートクラウドグループで、2ヶ月間のインターン（CA Tech JOB）を行いました上野裕一郎 (https://www.y1r.org) です。普段は東京工業大学で深層学習をスパコンなどの高性能計算技術で加速・大規模化させる研究をしています。 本インターンではSegment Routing、とくにSRv6を用いてKubernetesのPodネットワーキング機能(CNI)を実装しました。本稿では、CNIとSegment Routingについて紹介したのち、その実装と動作を説明します。 Container Network Interface;
整理しながら理解するKubernetesネットワークの仕組み / Kubernetes Network Fundamentals
#cndjp 第16回勉強会での発表資料です。 ・アジェンダ Kubernetesのネットワークには様々な登場人物があり一見すると複雑に思われがちですが、それぞれの役割と関係性を把握すれば決して難解なものではありません。 最後のセッションでは、そんなKubernetesのネットワークの仕組…
Cilium for Kubernetes networking: Why we use it and why we love it
Kubernetes networking Palark CNI eBPF Cilium for Kubernetes networking: Why we use it and why we love it Thanks to the CNI (Container Network Interface), Kubernetes offers a good deal of options to address your networking needs. After years of relying on a simple solution, we faced a growing demand for advanced features backed by our customers’ needs. Cilium brought the networking in our K8s platf
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
サービスメッシュの本質は、トラフィック管理や可観測性ではない
Abstruct サービスメッシュが、真に提供する価値は何なのか。それはトラフィック管理と可観測性なのだろうか。 サービスメッシュがこれほどにまで繁栄した理由について、私なりに考察する。 Introduction 近年では、ソフトウェアのアーキテクチャとして、マイクロサービスが大流行した。かつては最大手のインターネット企業のみが必要性に迫られていた、マイクロサービスアーキテクチャだが、昨今の急激に成長するITビジネスの中で、多くの企業にとってマイクロサービスは、あらゆる企業が取り組むべき必然性のあるソリューションとなっている マイクロサービス・アーキテクチャによって、大規模な開発チームがより俊敏になり、より多くのデプロイを実現させられることは、大きなメリットだ。一方で、マイクロサービス特有の課題も数多く存在する。 マイクロサービスに移行する際に発生する運用上の問題の多くは、結局のところ、ネ
「eBPF」がクラウドネイティブを超強力にする。eBPFとは何か？ 何ができて、どんな利点があるのか？ Cloud Native Days Tokyo 2022基調講演から
「eBPF」がクラウドネイティブを超強力にする。eBPFとは何か？ 何ができて、どんな利点があるのか？ Cloud Native Days Tokyo 2022基調講演から 2022年11月21日と22日の2日間、クラウドネイティブにフォーカスしたイベント「Cloud Native Days Tokyo 2022」が都内およびオンラインのハイブリッドで行われました。 22日の基調講演に登場したのは、Cilium、Hubble、TetragonなどeBPFを中心としたオープンソースを開発しているIsovalentのTracy P Holmes氏。 Homes氏は、いまクラウドネイティブ関連のテクノロジーとして最も注目されていると言ってよい「eBPF」を紹介するセッション「Cloud Native Superpowers with eBPF」を行いました。 eBPFとはどのようなテクノロジーな
非公式翻訳：eBPF Superpowers (CNDT2022 Keynote)
CloudNative Days Tokyo 2022 Day2が開幕しました。本日のキーノート枠では、Isovalent社のTechnical Community AdvocateであるTracy P Holmes氏から、クラウドネイティブな世界におけるeBPFの強力さについてお話いただきます。 日本語の字幕を用意するのが難しく、Mediumで同氏のセッションの書き起こしと日本語翻訳をご用意しました。セッション視聴のお供に、また後から見返すためにもお使いください！ （なお、本書き起こしと翻訳は非公式なものとなります。正確な内容を保証するものではなく、あくまでセッション視聴の参考とお考えください） 翻訳・編集：Yoshiki Fujiwara @antiberial, Kohei Ota @_inductor_, Hayakawa Yutaro @YutaroHayakawa, Masat
eBPFを用いたネットワーキングやセキュリティなど、AWS、Azure、Googleの3大クラウドが採用。Isovalentが明らかに
eBPFを用いたネットワーキングやセキュリティなど、AWS、Azure、Googleの3大クラウドが採用。Isovalentが明らかに クラウドネイティブな環境でeBPFを採用したネットワーキングやオブザーバビリティなどの機能を提供するオープンソースの「Cilium」を開発するIsovalentは、AWS、Microsoft Azure、Google Cloudの3大クラウドそれぞれのKubernetes環境でCiliumの採用が出揃ったことを、10月24日に米国ミシガン州デトロイトで行われたCloud Native eBPF Day NA 2022（KubeCon + CloudNativeCon NA 2022と同時開催）の基調講演で明らかにしました。 eBPFとは、Linuxカーネルのコードを変更することなく、カーネルの持つさまざまな機能をフックすることでカーネルに対してプログラマブ
servicemesh.es
What is a Service Mesh? A service mesh is a dedicated infrastructure layer that adds features to a network between services. It allows to control traffic and gain insights throughout the system. Observability, traffic shifting (for canary releasing), resiliency features (such as circuit breaking and retry/timeout) and automatic mutual TLS can be configured once and enforced in a decentralized fash
Kubernetes Security: 10 Best Practices from the Industry and Community
Kubernetes Security: 10 Best Practices from the Industry and Community Kubernetes requires extensive configuration, and keeping container security at the right level is always challenging. One of the best ways to tighten your clusters’ security is by implementing tactics that […] Kubernetes requires extensive configuration, and keeping container security at the right level is always challenging. O
【AWS】Pod毎にセキュリティグループを指定できるSecurityGroupPolicyについて
はじめに 最近AWSでPod毎にセキュリティグループを指定できるSecurityGroupPolicyが出たので、その紹介記事になります。 (2020/9なのでもう最近じゃない気もしますけど😇) SecurityGroupPolicy概要と利点 SecurityGroupPolicyとは、pod単位でセキュリティグループを指定できるようにする、AWS独自のkubernetesリソースの事です。 マイクロサービスなどで複数サービスを単一クラスタで管理する環境の場合、サービス(pod)単位でセキュリティグループを作成したくなること、ありませんか？(あるある！) 例えば、サービスAのRDSやElasticacheが、サービスBのpodからも自由にアクセス出来るって少し怖いですよね。(うんうん！) 上記のような問題をSecurityGroupPolicyは解決できます。(すごい！) 従来はNod
EKSのセキュリティグループについて理解する - Qiita
※ 2022年8月更新：ドキュメントが大幅に変わっていたため本記事も大きく書き換えました。 背景 EKSクラスターやワーカーノードに用いるセキュリティグループ（以下SG）には何種類かありますが、それぞれの役割について一部よくわからない部分がありました。 今回、AWSサポートへの問い合わせや動作検証によりきちんと調べてみたので、まとめていきたいと思います。 EKS関連SGの種類 EKS関連のSGは下記3種類がある。 クラスターSG コントロールプレーンSG ノードSG ノードSGがワーカーノードEC2に付与するSGっていうのは、なんとなく分かる。けど、1.と2.の違いがよく分からん。。という状態でした。 さらに検証進めていく中で、ノードSGも少し特殊な動作することがわかりました。 それぞれ詳しく 1. クラスターSG 下記3者に付与されるSG EKSコントロールプレーン通信用ENI（EKS-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kubeshark/kubeshark: The API traffic analyzer for Kubernetes providing real-time K8s protocol-level visibility, capturing and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters. Inspired by Wireshark
Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio
EKS — Security Groups for Pods
Istio入門
