About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day.
はじめに このエントリーはKubernetes Advent Calendar 2016の1日目の投稿になります。今年の8月頃から仕事でKubernetesを検証していたので、勢い余ってアドベントカレンダーを作ったところ、私以外にも24名の参加者が集まってくれました。今からどんなエントリーが集まるのか楽しみです。皆さん、よろしくお願いします! Kubernetesの世界を散策してみよう! そんなわけで、Kubernetesを使ってあれこれ検証しているわけですが、初回ということもあり、Kubernetesに関して知ることのできる情報をいくつか紹介しながら、その世界を散策したいと思います。 Kubernetes誕生の物語 まずは、Kubernetesがどのようにして生まれたのか?という話から覗いてみましょう。 Google から世界へ : Kubernetes 誕生の物語 こちらはGoogle
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Table of contents A bit of context About this presentation Overview of Kubernetes on AWS Detailed guide for kube-aws A bit of context Kubernetes AWS Why Kubernetes on AWS Why they matter to you Kubernetes in a nutshell An open-source system for automating deployment, sca
この記事はリクルートライフスタイル Advent Calendar 2016の10日目の記事です。 DEPRECATED! [2020/12/05追記] この記事内のコマンドは現在のバージョンの挙動と一部異なっていたり、説明に不正確な部分があります。 例えば公式のチュートリアルなど、信頼できる情報を参照ください。 https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/ 2019/05/30追記 下記内容は若干の不正確を含みますので、軽く読み流して雰囲気を掴んでいただいたあとは https://qiita.com/Kta-M/items/ce475c0063d3d3f36d5d などご参照いただくとよいかと思います。 こんばんは 「sshするときの-p 443ってなんの数字ですか?」ぐらいの素人がインフラ周りを担当し8ヶ月、kub
このエントリーは Kubernetes Advent Calendar 2016の12日目の記事です。 今回は Kubernetes を分散システムのフレームワークとして利用する方法について紹介しようと思います。 ThirdPartyResource まずフレームワークとしての利用方法の前にそれを実現するために利用する ThirdPartyResource について簡単に紹介します。 ThirdPartyResource(TPR) は Kubernetes のオブジェクト (Pod, Service, Node等)の一つです。 TPR は Kubernetes API を新しいオブジェクト型で拡張する方法を提供します。 TPR オブジェクトを追加することでユーザ独自の新しいオブジェクト型の API を追加することができます。このユーザ独自の新しいオブジェクト型の API は CRUD の操
参考 Kubernetes architecture 2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters and Where We're Going Next etcd v3 as storage backend for APIServer #44 Kubernetes: 構成コンポーネント一覧 Kubernetes: コンテナが起動するまでの各コンポーネントの流れ 複数クラスタ連携 (Federated Kubernetes) Federated Kubernetesは複数のKubernetesを連携させる機能です。Ubernetes("uber-"は"超える"の意味の接頭辞)とも呼ばれます。AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタ
$ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/service.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/deployment.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/configmap.yml 検証に利用した Kubernetes リソースは次のとおりです. Service kkohtaka/kubernete
この記事は、「Kubernetes Advent Calendar 2016」18日目の記事です ここでは Kubernetes がサポートする認証方法全てを手元で試してみたいと思います。 機能の説明は書いてあるが実際の使い方まで詳しく書いておらず、使い方がわからないものがあったりしたのでこれを機に全パターン確認してみます。 また、この記事は kubernetes: 1.4.6 および minikube: v0.13.1 で確認しています。 まずは簡単に kubernetes における認証の流れについておさらいしておきます。 kubernetes においては、ユーザーからコンテナの操作要求(CLIなどを使って)を受け取ると、クラスタを利用可能なユーザーであるかを認証し、利用可能な操作を認可で確認するというのが基本的な認証・認可の流れになります。(+ AdmissionControl もある
この記事はKubernetes Advent Calendar 2016の19日目の記事です。前日はhiyoshiさんの「kubernetesがサポートする認証方法の全パターンを動かす」でした。 数ヶ月前からKubernetesの環境を触り始めた自分としては、あっという間に1.5がリリースされているKubernetesにただただ驚くばかりです。 そんな1.2時代の知識・経験しかないエンジニアが1.5を触った所感を書きたいと思います。ちなみに1.2を利用していた頃のメモはこちらに載せています。 #今回本当に初見で1.5を触っていますので、間違っている箇所などありましたら訂正コメント頂けるとありがたいです。 前提 kubeadm 1.6系を利用します。Kubernetesは1.5系になります。 Master1台、Node1台の構成で一旦動かします。 サーバにはAWSのEC2インスタンス(Cen
公式レポジトリ 公式レポジトリではstableとincubatorの2つに分けて管理されています。kubernetes/chartsのstableの説明によると下記のポリシーで運用されています。 データ永続化の方法が提供される アプリケーションのアップグレードがサポートされる アプリケーション設定のカスタマイズを許可する セキュアなデフォルト設定を持つ Kubernetesのアルファ機能を利用しない 公式レポジトリ以外に任意のレポジトリを使用することも可能です。なお、現在は下記のパッケージが提供されています。 Stable drupal jenkins mariadb mysql redmine wordpress Incubator consul elasticsearch etcd grafana mongodb patroni prometheus spark zookeeper 旧
概要 この記事はKubernetes Advent Calendar 2016の12/21の記事です。 kubernetesは分散アプリケーションをうまく管理することができる素敵なソフトウェアです。 仕事でもちょこちょこ触っているのですが、今回はAdventCalendarということでkubernetesの紹介がてら、ちょっとおもしろいものを作ってみようと思います。 kubernetesはユーザの操作とは非同期に動いていて、ユーザが指示を出しても、その結果が完全に反映されるまでに少し時間がかかります。 また、ユーザが操作していなくても、障害などがあれば勝手にシステムを正しい状態に戻してくれます。 この挙動は分散アプリケーションを扱う上ではとても良いのですが、利用者からすると、「いつ、何が起きているのか?」がわかりにくいことがあります。 ということで、「今kubernetesの中で何が起きて
この記事は Kubernetes Advent Calendar 2016 の22日目の記事です。 Kubernetes を使っていると、 Pod 内のコンテナで動くプロセスから使われるデータを GitHub repository の HEAD に同期して更新したいというような場合が出てきます。 例えば、下記のような場合があります。 CDN を使わずに小規模に配信するコンテンツ DBMS に入れるほどではないデータファイル このような場合に、プロセスだけでなくデータに対してもデプロイフローを作ると複雑になるので、できれば避けたいところです。 今回は、プロセスが使うデータを自動的に GitHub と同期する方法を紹介します。(実際は GitHub に限らず Git 一般に対応可能です。) gitRepo Volume では駄目なのか Kubernetes には組み込みの gitRepo Vo
みなさま、クリスマスケーキの準備はできていますでしょうか? 本エントリーはKubernetes Advent Calendar 2016の23日目、クリスマス・イブ・イブの記事です。 今回は、Ansibleを利用してKubernetes上にコンテナを簡単にデプロイする方法について紹介したいと思います。 何で、Kubernetes Advent CalendarなのにAnsibleかといいますと。まぁ…。マイブームみたいなもんです。 Promotion!! Ansibleってどうやって使うの?って方は、是非×2、こちらも見て頂けるとうれしいです。 Qiita 「Ansible実践ガイド」出版しました。 レビュー、感想お待ちしております。 概要 さて、今回はKubernetes環境をAnsibleで作ろうっ!!というタイトルではありません。 Ansibleを利用したKubernetes環境のセ
これはKubernetes Advent Calender 2016の12月24日のエントリです。23日のしんごちゃんのエントリはお楽しみいただけたでしょうか。本買ってあげてください。俺も買ったよ!まだ読んでないけど! 師走だなあ メリークリスマス!ほーっほっほーう!笑ゥせぇるすまんぢゃないよ!ほーっほっほーう! 私はイタリア人のカトリック教徒ですので、家族と半日かけて黒トリュフのパスタと七面鳥の丸焼き等のディナーをプロセッコやモンテプルチアーノのワインと共にいただくのがいつものクリスマスイブの過ごし方なのですが(嘘です)、今年は長男が受験生のためクリスマスツリーすらありません(これは本当です)。そしてどうやらひどく酔っぱらっていたときにKubernetesのアドベントカレンダーにエントリーしていたようです。せっかくですので、**これがHPEの本気だ。Kubernetesを商用プライベート
この記事は Kubernetes 1.5.2 で確認した情報を元に記載しています。 Deployment Deploymentはローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するものです。 Deployment の仕組み 下記の図のようにDeploymentはReplicaSetを生成・管理し、ReplicaSetはPodを生成・管理します。 ReplicaSet(ReplicationControllerの後継)はPodTemplateと呼ばれるPodのテンプレートをもとに、Podを指定された数(レプリカ数)に調整・管理を行う仕組みです。Podがレプリカ数より足りない場合はPodを追加し、多い場合はをPodを削除します。この仕組みによってノードの障害やアプリケーションのクラッシュでPodが足りなくなった際も自動的にPodが追加され、セルフヒーリングが実現されていま
GoogleCloudPlatform ContainerEngine(Kubernetes)でコンテナ管理入門(基本的な使い方、Registry、Blue/Green Deployment、ResizeCluster、MultiZoneClusterとか)DockerkubernetesGoogleContainerEngineGoogleContainerRegistryGoogleCloud はじめに 先日GoogleCloudOnBoardという大きなイベントに参加しまして、色々と感動したわけです。私もGCP布教に一役買おうと思いContainerEngineについて書いてみました。 前回はAWS ECSを書きましたけど、やっぱりコンテナ管理といえばKubernetesですよ。 今回も前回とだいたい同じシナリオでやってみたいと思いますが、Autoscalerだけはベータでの提供との
本スライドは「Kubernetes Meetup Tokyo #3」の登壇資料です。 Highly available and scalable Kubernetes on AWS TL;DR; 「高い可用性とスケーラビリティを確保したKubernetesクラスタを、AWS上で本番運用するにあたって得られた知見」を共有します 「コンテナベースのインフラをAWSで本番運用したい方」向けに話します KubernetesやAWSについてはある程度わかっている前提 自己紹介 twitter/github/slack.k8s.io: @mumoshu (むもしゅ) 数十人くらいの規模のWeb企業でインフラエンジニアとして働いています 半分仕事で、kube-awsというOSSの唯一のメンテナをしています kube-aws: https://github.com/coreos/kube-aws アジェン
TL;DR Kubernetes でマルチコンテナな Pod はよく使われる Cloud SQL Proxy はサイドカーコンテナとして動く前提 Job の完了には Pod を構成するプロセスが完了する必要がある PID Namespace は未実装 シグナルが送れない 完了しないと不意に再開する サイドカーコンテナを殺すためのプログラムを書いてみた サイドカーコンテナパターン Kubernetes は複数のコンテナからなる Pod を最小の単位として扱う。Google の社内コンテナ管理システムの Borg にも同様の仕組みがあり、その経験から「Design Patterns for Container-based Distributed Systems」でコンテナデザインパターンとして複数コンテナの連携のパターンを定義している。 このコンテナデザインパターンの中でも頻出するのが、メイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く