EM完全に理解した と思ったけど、 やっぱり何も分からなかった話 / EM Night Fukuoka #1
概要 Kubernetesには以下のフィールドでCPUやメモリを制限することが可能です。 spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory ref: Resource Management for Pods and Containers | Kubernetes cpu: 1、cpu:2といった整数値はイメージが湧きやすいですが、 cpu: 100mといった時にどういう動きをするのか? マルチコアのノード環境で↑の時、アプリケーションコードでマルチコア前提のものはきちんと動くのだろうか? という疑問があったので調
クラウドサービスのインスタンスは用途に応じて「汎用」「メモリ特化」「GPU特化」といった具合で、さまざまなカスタマイズが可能。しかし、あまりにも選択肢が多すぎて比較検討が難しいのも事実です。そんなインスタンスの価格やスペック比較を簡単に行えるウェブサービス「EC2Instances.info」をVantageが公開しているので、実際に使ってみました。 Amazon EC2 Instance Comparison https://instances.vantage.sh/ EC2Instances.infoはAmazon EC2とAmazon RDSのインスタンスを比較検討できるサービス。さっそくアクセスしてみると、EC2インスタンスの名称やメモリ、仮想CPU(vCPU)数、ストレージ、ネットワーク性能、利用料金が表示されました。デフォルトでは利用可能なすべてのインスタンスが表示されている状
日産DOPナビMM514D-LはSDカードの動画再生に対応しているのを最近知りました。 1年以上使ってるのに気づかないとは。 YOUTUBEからダウンロードした動画とか変換してSDに入れると車で楽しむことができます。 たぶんMM515でも応用できるかと。 XMedia Recodeを使う場合は カスタムで”MP4”を選択。 ビデオは”MPEG-4”を選択。 音楽トラックはコーデックにAACを選択。 アスペクト比を保持をチェックして、マニュアルに載っているサポートしている解像度内になるよう指定します。 これで変換して、SDカードにコピーすると楽しめるはずです。 いろいろ指定が面倒だという方は”すーぱー連続動画変換”を使うと楽です。 MM514D-L向けの設定ファイル作成したので、使ってみてください。 私の別ブログの記事からダウンロードできます。 MM514D-L向け”すーぱー連続動画変換”i
sparsebundlefs を使ってがんばります。 mountしたりするのでrootでの作業です。 とりあえず作業用ディレクトリへ行って、使うツールの下準備 $ git clone https://github.com/torarnv/sparsebundlefs.git $ cd sparsebundlefs $ make timemachineのsparsebundleをマウントしてdmgを見れるようにする。 $ mkdir dmg $ ./sparsebundlefs /YOUR_PATH_TO_SPARSEBUNDLE ./dmg dmgをマウントする。うまくいかない時は、parted使ってoffsetとか確認してloopインターフェス作ってマウントする。 $ mkdir tm $ mount -o loop -t hfsplus ./dmg/sparsebundle.dmg .
「キャッチアップしておきたいウェブ制作の最前線」というテーマで、Vue.jsなどJavaScriptを駆使したユーザーインターフェイスの開発を主に担当してきた池田泰延氏が、Webのフロント周りの近年の技術的な動向を解説します。前半はフロントエンド技術のトレンドについて。 スピーカー自己紹介、『JavaScript コードレシピ集』を出版 池田泰延 氏(以下、池田):みなさんよろしくお願いします。ICSの話として、私と鹿野の2名で発表します。HTMLとかCSSとかJavaScriptとか、フロントエンドまわりの最新を説明していきたいと思います。では始めていきましょう! ます自己紹介します。ICSの池田と言います。株式会社ICSの代表をやっています。これはオフィスの写真でして、南麻布にあるのですが、こんなところで仕事をやっています。今はこの状況下なので、会社にはほとんど誰も行っていませんが、こ
Git のトラッキングブランチの確認と設定方法 作成日 2018.08.11 更新日 2018.08.15 Git Git でリモートブランチをトラックするローカルブランチをトラッキングブランチと言いますが, トラッキングブランチとはどういうものなのか, どのように確認できるのか, 設定できるのかということを紹介します. Git のバージョンは 2.18.0 です. トラッキングブランチとそうでないブランチの違い そもそもとしてトラッキングブランチとそうでないブランチの違いを軽く説明させていただきたいと思います. まずトラッキングブランチは git clone <repository> でクローンすると自動的に, <repository> のアクティブなブランチが, トラッキングブランチとして作られます. 通常は master というブランチが, トラッキングブランチとして作られます. そ
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編) Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
This article uses Istio's official bookinfo example to explain how Envoy performs routing forwarding after the traffic entering the Pod and forwarded to Envoy sidecar by iptables, detailing the inbound and outbound processing. For a detailed analysis of traffic interception, see Understanding Envoy Sidecar Proxy Injection and Traffic Interception in Istio Service Mesh. NOTE: This blog is mostly tr
chart のテストは https://helm.sh/docs/topics/chart_tests/#helm にあるように、実際に helm install する必要があります。 そうではなくて、単純に吐き出される manifests が期待したものかどうかをテストしたいというケースもあると思います(僕はあった)。 helm template --execute (v3 だと --show-only) を使って出力されたファイルを使ってテストをする方法もありますが、あまりスマートとは言えない感じがします。 そこで terratest を使ってテストを書く方法についてメモがてら残します。 とりあえず適当に chart を作ります。 ❯ tree . ├── Chart.yaml ├── charts ├── templates │ ├── _helpers.tpl │ └──
Kubernetes 1.20から始まるDockerランタイムの非推奨化に備えよう!我々が知っておくべきこと・すべきこと はじめに Kubernetesの次のマイナーバージョン1.20が、2020年12月8日にリリースされました。今回のリリースではGraceful Node Shutdownの追加やkubectl debugのBeta昇格など、運用に嬉しいさまざまな機能のアップデートがあります。その中でも、12月初頭にGitHubや公式Slack、Twitterなどを賑わせたのがDockershimの非推奨化でした。公式のリリースノートには以下のように書かれています。 Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a modu
これは、なにをしたくて書いたもの? Elasticsearchクラスタのシャード数やノード数を算出する時の考え方についていろいろ調べたので、メモをしておこうかなと。 Elasticsearchクラスタでのシャード数とノード数を計算する 基本となるのは、以下のブログエントリでしょう。 How many shards should I have in my Elasticsearch cluster? | Elastic Blog こちらに、シャードひとつあたりのサイズについての考え方が書かれています。 ヒント: 小さなシャードは小さなセグメントとなり、結果としてオーバーヘッドが増えます。そのため、平均シャードサイズは最小で数GB、最大で数十GBに保つようにしましょう。時間ベースのデータを使用するケースでは、シャードサイズを20GBから40GBにするのが一般的です。 20〜40GBにするのが、
概要 最近のGKEはContainer Nativeなロードバランシングを推奨しています。 これは、Alias IP, NEGという仕組みを使って、GCPのロードバランサーがPodのIPに直接ルーティングすることができます。 しかし、適切にPodを設定していない場合、クラスタのメンテナンスなどでノードからPodがevictされたときにダウンタイムが発生してしまいます。 この記事ではContainer Native LoadBalancerの仕組みと、Podの適切な設定について説明していきます。 Container Nativeなロードバランシングの仕組み Container Native LoadBalancingに記載してある通り、 引用: Container Native LoadBalancing GKEのMasterノードにNEG ControllerというCustom Contr
追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね!!!」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合
GKEのNodeをCoreOSを使っていれば、CoreOS toolboxを使って1 回だけ必要なパッケージやツールを追加でインストールし実行することができます。 cloud.google.com このCoreOS toolboxを使ってstraceをワンタイムでインストールしてpodの状態を確認します。 straceで調べたいPodが動いているNodeを探す consoleからでもなんでもいいので調べます。 kubectl get pods -o wide のようにwideオプションつけると、Nodeも表示されます。 Nodeにsshで入る GCPのconsoleからgcloudのコマンドを表示して入ることが多いです。 Podのプロセスを探す ps auxwwf などでプロセスを出せば、Podで動いているプロセスも見れます。 ここでstraceを打ちたいPIDを控えておきます。 tool
本記事では、Istioを用いてKubernetesの1つのNamespace内でService Meshを実現することを目的としています。(もちろん、Service MeshはKubernetesのNamespaceやクラスタに閉じるものではありません。) Service Meshが必要だと感じるプロダクトは既にアーキテクチャが複雑になっているはずなので、Istioのチュートリアルで出てくるBookinfo ApplicationほどスムーズにIstioを導入することは難しいと思います。いきなり広い範囲にService Meshを導入するより、Service Meshの範囲をインクリメンタルに広げていく方が、Service Mesh導入の難易度は下がります。影響範囲が局所化されるので、問題が発生しても原因の特定が容易になるためです。また、サービスとして動く状態を維持しつつ、少しずつリリース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く