OpenShift 3.11のRelease Note抄訳
2018/10/10(日本時間では10/11未明)にOpenShift 3.11がリリースされました。
4.0に向けて着々と新機能が投入されていますが、特に注目すべきはPrometheusのGAとOperator Frameworkです。Operator FrameworkはOpenShift内部だけでなく、Red HatのプロダクトやISV製品の基盤となる仕組みなので要注目です。
元情報
OpenShift Container Platform 3.11 Release Notes
https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html
このリリースについて
このリリースはKubernetes1.11を含むOKD3.11をベースにしている。
RHEL7.4および7.5上で、CRI-O1.11およびDocker1.13を含むExtrasチャネルの最新パッケージをサポートする。
以前のバージョンからのアップグレードはドキュメント(https://docs.openshift.com/container-platform/3.11/upgrading/index.html#install-config-upgrading-index)を参照。
注) 3.10へのダウングレード
OCP3.11の初期リリースでは、3.10へのダウングレードに問題があるため行わないこと。将来のリリースで修正される予定。
https://bugzilla.redhat.com/show_bug.cgi?id=1638004
4.0で予定されている主要な変更
OCP3.11は3.xの最後のリリースで、4.0では内部アーキテクチャやインストールプロセスが大きく変更される予定であり、多くのフィーチャーが廃止される。
4.0で廃止されるフィーチャー
フィーチャー | 理由 |
Hawkular | Prometheusにリプレース |
Cassandra | Prometheusにリプレース |
Heapster | Metrics-ServerかPrometheus metrics adapterにリプレース |
Atomic Host | Red Hat CoreOSにリプレース |
System containers | Red Hat CoreOSにリプレース |
projectatomic/docker-1.13 additional search registries | CRI-OがRHCOSおよびRHELに対するデフォルトのコンテナランタイムに |
oc adm diagnostics | Operatorベースのdiagnosticsに変更 |
oc adm registry | registry operatorにリプレース |
Custom Docker Build Strategy on Builder Pods | カスタムビルドの利用を継続する場合はDockerコマンドをPodmanとBuildahに置き換える必要あり。カスタムビルドストラテジは存続するが、OCP4.0では機能が大幅に変更される。 |
Cockpit | Quayにリプレース |
Standalone Registry Installations | エンタープライズコンテナレジストリとしてQuayを提供 |
DNSmasq | CoreDNSがデフォルトに |
External etcd nodes | 4.0ではetcdは常にクラスタ上にデプロイされる |
CFME(CloudForms) OpenShift Provider and Podified CFME | Prometheusにリプレース |
Volume Provisioning via installer | Dynamic Volumeでリプレース、ないしはNFSが必要ならNFS provisionerを利用 |
Blue-Greenクラスタアップグレード | 4.0ではアップグレードが容易になることが目玉の一つ |
OCP4.0では大幅な変更が予定されているため、ドキュメントも大幅に改廃される予定。
主なアップデート(カテゴリ別)
[TP]はTechnology Preview、すなわち、プロダクション環境ではサポートされないフィーチャーです。
開発テスト環境などの非プロダクション環境では問題なくご利用いただけます。
Operator関連
[TP]Operator Lifecycle Manager(OLM)
Operator SDK
Operator SDKはコード生成とCLIによってOperatorの実装、テスト、パブリッシュを容易にするための開発ツール
- アプリケーションのビジネスロジックを迅速にOperatorに組み込むためのツールを提供
- Kubernetes APIとコミュニケーションするための定型的なコードを自動生成
- ローカル/リモートクラスタでエンドツーエンドのテスト実行を支援
- Couchbase, MongoDB, Redisやその他のOperatorで利用されている
詳細はOKDのドキュメントを参照
https://docs.okd.io/latest/operators/osdk-getting-started.html
Service Broker関連
OpenShift Automation BrokerとAnsible Galaxyの統合
Automation Broker(Ansible Broker)が利用するAnsible Playbook Bundle(APB)をAnsible Galaxyから検索して実行できるようになった。
詳細はドキュメントを参照
https://docs.openshift.com/container-platform/3.11/architecture/service_catalog/ansible_service_broker.html#arch-ansible-service-broker
インストールとアップグレード
アップグレード時の証明書有効期限チェック
openshift_certificate_expiry_warning_daysを指定すると、アップグレード時に自動生成された証明書の有効期限が指定日数より短い場合にwarningが発生する。
openshift_certificate_expiry_fail_on_warnを指定することで、有効期限が短い場合にアップグレードをfailさせることができる。
https://docs.openshift.com/container-platform/3.11/install/configuring_inventory_file.html#configuring-cluster-variables
Ansilbe2.6サポート
OCP3.11のインストールおよびOCP3.10からのアップグレードにはAnsible2.6.xが必要。
Ansible2.7はまだサポートされていない。
レジストリ認証クレデンシャルが必須に
コンテナイメージとメタデータの取得先が registry.redhat.io に変更されたため、認証が必須になった。
inventory fileで以下の設定が必須
- openshift_deployment_type == ‘openshift-enterprise’
- oreg_url == ‘registry.redhat.io’ or undefined
- oreg_auth_user および oreg_auth_password
その他の認証ありレジストリ(プライベートレジストリ)からイメージを取得することも可能。詳細はドキュメントを参照。
https://docs.openshift.com/container-platform/3.11/dev_guide/managing_images.html#private-registries
デフォルトでインストールログが取得されるようになった
Ansibleのlog_pathが設定されているので、playbookの実行は /usr/share/ansible/openshift-ansible ディレクトリから行う必要あり。もしくはlog_pathを変更すること。
ストレージ関連
[TP]Container Storage Interface
CSIを実装したストレージバックエンドが利用可能。詳細はドキュメント参照。
https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/persistent_storage_csi.html#install-config-persistent-storage-persistent-storage-csi
[TP]Local Ephemeral Storageの保護
Nodeのローカルストレージが枯渇することを防止する。
デフォルトでは無効化されている。
https://docs.openshift.com/container-platform/3.11/install_config/configuring_ephemeral.html#install-config-configuring-ephemeral-storage
[TP]Openstack ManilaによるPVのプロビジョニング
NFSシェアタイプのみ対応。
https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/persistent_storage_manila.html#persistent_storage_manila
[TP]PVリサイズ
GlusterFSの場合はStorageClassのallowVolumeExpansionをtrueにすることで、PVCのサイズを拡張するだけで対応するPVのリサイズが行われる。
ブロックストレージ(GCE-PD,AWS-EBS,Azure Disk,Cinder, Ceph RDBなど)の場合はボリューム拡張が必要で、通常はPVを参照するPodがリスタートした際にKubernetesが自動的にファイルシステムの拡張を行う。
ネットワークファイルシステム(GlusterFS,Azure Fileなど)の場合はファイルシステムの拡張が不要なので、Podをリスタートしなくても拡張できる。
https://docs.openshift.com/container-platform/3.11/dev_guide/expanding_persistent_volumes.html#expanding_persistent_volumes
スケーラビリティ関連
Cluster Limits
ガイドがアップデートされた
https://docs.openshift.com/container-platform/3.11/scaling_performance/cluster_limits.html#scaling-performance-cluster-limits
Masterに対する推奨事項
大きいクラスタ、ないしは高密度なクラスタに対しては、デフォルトQPS(query per second)の制限によってAPIサーバーが過負荷になる可能性があるため、/etc/origin/master/master-config.yaml を修正してQPSの制限を増やす。
Masterに対する推奨プラクティスはこちらを参照。
https://docs.openshift.com/container-platform/3.11/scaling_performance/host_practices.html#scaling-performance-capacity-host-practices-master
Cluster Monitoring Operatorのスケールアウト
OCPのメトリクスはcluster-monitoring-operatorが提供するバックエンド(PrometheusとGrafana)によって収集/格納され、参照可能になっている。
OCP3.11ではデフォルトでInfraNode(node-role.kubernetes.io/infra=true)にCluster Monitoring Operatorがインストールされるので、InfraNodeを複数台用意するか、inventory fileでインストール対象のNodeを指定(openshift_cluster_monitoring_operator_node_selector)して、Operatorが適切にスケールされるようにしておくこと。
https://docs.openshift.com/container-platform/3.11/scaling_performance/scaling_cluster_monitoring.html#scaling-performance-cluster-monitoring
メトリクスとロギング
Prometheus Cluster Monitoring
Prometheus Cluster Monitoringがフルサポートになり、デフォルトでクラスタにデプロイされる。
[TP]Syslog Output Plug-in For Fluentd
Fluentd Syslog Output plug-inにより、OCPノードから外部のSyslogサーバーにシステムおよびコンテナのログを送信可能。
https://docs.openshift.com/container-platform/3.11/install_config/aggregate_logging.html#sending-logs-to-external-rsyslog
Elasticsearch5およびKibana5
ElasticsearchとKibanaのバージョンアップ。
Kibanaダッシュボードの保存と複数ユーザー間での共有に対応。
Developer Experience
[TP]CLI Plug-in
ocコマンドの拡張が可能
https://docs.openshift.com/container-platform/3.11/cli_reference/extend_cli.html#cli-reference-extend-cli
Build Triggerの挙動を設定可能に
ImageChangeTriggerを一時停止(paused=true)することが可能になり、ビルド実行前にImage Streamに対する複数回の変更を許容できるようになった。
ビルドにConfigMapやSecretを受け渡す方法の追加
SCM以外にも様々な方法で受け渡せるようになった。
https://docs.openshift.com/container-platform/3.11/dev_guide/builds/build_inputs.html#dev-guide-build-inputs
Kubectl
oc client downloadからkubectlがダウンロード可能になるとのこと。
https://access.redhat.com/downloads/content/290
=>10/15時点では以前と変わらずocコマンドしかダウンロードできなかった。これから対応?
Quay
Red Hat Quayレジストリ
ホステッドサービス(quay.io)とソフトウェアの両方を提供。ジオレプリケーション、イメージスキャン、イメージロールバックなどの高度な機能を含む。
https://docs.openshift.com/container-platform/3.11/architecture/infrastructure_components/image_registry.html#architecture-infrastructure-components-image-registry
ネットワーク
[TP]KuryrによるOpenShiftとOpenStackの統合
https://docs.openshift.com/container-platform/3.11/admin_guide/kuryr.html#admin-guide-kuryr
https://docs.openshift.com/container-platform/3.11/install_config/configuring_kuryrsdn.html#install-config-configuring-kuryr-sdn
Router(HAProxy)の拡張
- HTTP/2対応(Routerでterminate)
- スレッド数変更対応
- 動的変更(Routerを再起動せずに変更を反映)
- mTLSサポート
- logging(EFK)によるログ収集
Namespace毎のHA Egress IP
Namespaceに対してactive/backup方式でのHA Egress IPを付与
https://docs.openshift.com/container-platform/3.11/admin_guide/managing_networking.html#enabling-static-ips-for-external-project-traffic
Namespace毎の全自動HA Egress IP
Namespaceに対して全自動HA方式で Egress IPを付与
Master
Pod PriorityとPreemption
Podの相対的な優先度を指定してスケジューリングやリソース枯渇時のevictionなどの順序を制御できる。
https://docs.openshift.com/container-platform/3.11/admin_guide/scheduling/priority_preemption.html#admin-guide-priority-preemption
[TP]Descheduler
クラスタへのノード追加時などにノードのリソース利用状況の偏りが発生するのを防止するために再スケジューリングを行う
https://docs.openshift.com/container-platform/3.11/admin_guide/scheduling/descheduler.html#admin-guide-descheduler
[TP]Podman
OCIコンテナやPodを実行するためのデーモンレスツール
[TP]Node Problem Detector
Nodeレベルの問題を検出し、API Serverに報告するDaemonSet
https://docs.openshift.com/container-platform/3.11/admin_guide/node_problem_detector.html#admin-guide-node-problem-detector
クラスタオートスケーリング(AWSのみ)
ワークロードに応じてアクティブなノード数を自動調整。
https://docs.openshift.com/container-platform/3.11/admin_guide/cluster-autoscaler.html#configuring-cluster-auto-scaler-AWS
Webコンソール
Nodeレベルの情報提供
ノードの管理や障害対応のために以下を提供
- ノードステータスイベント
- node-exporterとkube-state-metrics
- RBACによるメトリクスの保護
- メトリクス参照用ロール(cluster-reader)
Kubernetesオブジェクトの管理
以下のオブジェクトの参照/編集/削除が可能
- ネットワーク
- Route / Ingress
- ストレージ
- PV / PVC
- StorageClass
- 管理
- Project / Namespace
- Node
- Role / RoleBinding
- CustomResourceDefinition(CRD)
クラスタワイドのイベントストリーム
権限のある全てのProject/Namespaceのイベントをフィルタリングして参照可能
マイクロサービス
[TP]Red Hat OpenShift Service Mesh
Istioベースのサービスメッシュ層を提供。
https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#product-overview
Notable Technical Changes
特に重要な変更についての技術的な解説があります。
https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html#ocp-311-notable-technical-changes
推奨されるストレージドライバの変更
よりよいパフォーマンスのため、Docker engineではoverlayfs2を、CRI-OではoverlayFSを推奨。(従来はDevice Mapperを推奨していた。)
OpenShift 3.10のRelease Note抄訳
2018/7/30(日本時間では7/31未明)にOpenShift 3.10がリリースされました。
4.0に向けての準備的なアップデートが多いのですが、Device PluginがGA(プロダクションサポート)になったり、ストレージ関連でいくつか意欲的な機能拡張が入ったりしていますので、自分用の備忘も兼ねてまとめておきます。
元情報
OpenShift Container Platform 3.10 Release Notes
https://docs.openshift.com/container-platform/3.10/release_notes/ocp_3_10_release_notes.html
稼働環境
ベースOSはRHEL7.4および7.5がサポート対象、Dockerは1.13がサポート対象です。
主なアップデート(カテゴリ別)
[TP]はTechnology Preview、すなわち、プロダクション環境ではサポートされないフィーチャーです。
開発テスト環境などの非プロダクション環境では問題なくご利用いただけます。
インストール
- コントロールプレーン(etcd / APIServer / controllers)はstatic podとして起動するように変更された。他の実行形態はサポート対象外となった。Containerized modeはサポート対象外。
- openshift-sdnとopenvswitchもdaemonset(コンテナ)で実行
- systemd起動ではなくなるので、/etc/sysconfig/atomic-openshift-api などの設定ファイルは使わず、/etc/origin/master/master.envを利用してstatic podを設定する。
- デバッグ支援のために次の便利コマンドが/usr/local/binに追加されている。
- Atomic Hostはdeprecatedになった。3.11まではサポートされるが、4.0でremoveされる予定。
ストレージ
スケール(パフォーマンス関連)
ネットワーク
- Routeの同時接続数の制限が可能に(アノテーションhaproxy.router.openshift.io/pod-concurrent-connectionsが追加)
- KubernetesのIngressオブジェクトをサポート(Ingressの作成と同期してRouteを自動生成)
- Egress RouterでDNS名による設定が可能に
- Serviceネットワークのアドレスレンジ拡張が可能に
- [TP]KuryrによりOpenStackとOpenShiftのネットワークの統合をより緊密に(OpenStack側のテナントの利用など)
Master/Node
メトリクスとロギング
- [TP]Prometheusは引き続きTPだが、バージョンが更新され、node-exporterが追加された
- [TP]Fluentdのsyslog output plug-inのサポート
開発者向け機能
Webコンソール
- サービスカタログ検索機能の強化(タイトル/説明/tagによる重み付けに対応)
- 複数Route存在時のデフォルトルートの指定を可能に(console.alpha.openshift.io/overview-app-route: ‘true’)
- 空のSecretの作成を可能に
- xterm.jsの更新によるパフォーマンス改善
- Deploy Image画面からpull secretを直接指定可能に
セキュリティ
- etcdに対するTLS Cipher Suiteの指定が可能に
- [TP]コンテナ間でのPID namespaceの共有の制御が可能に
ドキュメンテーション
- Quick Installationを削除
- Manual Upgradeを削除
- Installation GuideとConfiguration Guideを分離(読みやすさのため)
その他
"Notable Technical Changes"には、特に重要な変更についての技術的な解説があります。
https://docs.openshift.com/container-platform/3.10/release_notes/ocp_3_10_release_notes.html#ocp-310-notable-technical-changes
書籍「コンテナ・ベース・オーケストレーション」の紹介
はじめに
3/15に「コンテナ・ベース・オーケストレーション」が刊行されてから2ヶ月たちました。脱稿まで時間がかかってしまい、編集担当の方には大変ご苦労をかけてしまいましたが、そこそこ売れているようでホッとしております。
書籍の位置づけ
まえがきにも記載がありますが、自分としては企画段階で「プロダクション環境でコンテナを使う人のためのカタログ」ということを念頭に置いていました。そのため、DockerとKubernetesというデファクトスタンダードを重点とし、特にオーケストレーション機能の中心となるKubernetesについては多くの紙面を割いています。
背景
「2018年はコンテナ元年」=日本でもプロダクション環境をコンテナベースで運用する時代が到来する、という確信がありました。これは
- 前職での経験(IoTプラットフォーム)から、長期的にはハイブリッドクラウドがメインストリームになるという予想
- ハイブリッドクラウド、特にエッジコンピューティングとクラウドの併用のためにはアプリケーションのポータビリティが不可欠で、現時点での最適解はコンテナ
- 2017年初頭の時点でコンテナオーケストレーションプラットフォームとして完成度が高いのはKubernetes
- グローバルのユーザー動向を見ると、この数年でコンテナ(特にKubernetes)へのシフトが顕著になってきている
- 分散システムの基盤としてコンテナ(特にKubernetes)が主流になりつつある
ということを総合的に判断して、自分なりに立てたビジョンです。
執筆した箇所について補足
自分は4章「Kubernetes概要」の執筆を担当しましたが、4章ではKubernetesの各種マネージド・サービスやディストリビューションを選択する前提知識としての「Vanilla Kubernetes」を理解し、そのエッセンスを体得していただくことを目的としました。
そのため、環境依存の大きいネットワークについてはあえて割愛*1し、逆に、重要である割には情報の少ないPersistent VolumeやConfigMapについての解説を厚めにしています。
また、自分のマシンでKubernetesが一通り試せるように、Minikubeによるチュートリアルにも多くの紙面を割いています。執筆開始時点での取り決めによりKubernetes1.7ベースの内容になっていますが、最新バージョンとの差分情報は適宜補足していますので、読者の皆様にぜひ確認していただければと思っています。
執筆者ごとの担当章
書籍をご購入いただいた方から必ず聞かれるので、こちらにまとめておきます。(著者紹介に書いておくべきでしたが、脱稿作業に追われてそこまで気が回りませんでした。申し訳ありません。)
著者(敬称略) | 章 | タイトル | 内容 |
---|---|---|---|
前佛雅人 | 第1章 | コンテナ管理技術の普及とオーケストレーションを取りまく動向 | コンテナに至る技術動向の整理と現状の解説 |
前佛雅人 | 第2章 | Docker コンテナの基礎とオーケストレーション | Docker(Swarm含む)の技術解説 |
山田修司 | 第3章 | CaaS(Container as a Service) | さくらインターネットのArukasの開発者としてのCaaSの解説 |
須江信洋 | 第4章 | Kubernetesによるオーケストレーション概要 | Vanilla Kubernetesの基礎の理解と体験 |
佐藤聖規/福田潔 | 第5章 | GKE(Google Kubernetes Engine) | マネージドサービスのパイオニアであるGKEとGCPの解説 |
青山尚暉/市川豊/矢野哲朗 | 第6章 | Rancher | Rancher1.xと2.x(Kubernetesベース)の最速解説 |
境川章一郎 | 第7章 | Kubernetes on IBM Cloud Container Service | IBMが提供するマネージドKubernetesの解説 |
橋本直哉 | 第8章 | OpenShift Networking & Monitoring | Kubernetes商用ディストリビューションであるOpenShiftのOps向け紹介 |
平岡大祐 | 第9章 | OpenShift for Developers | 同じく0penShiftでDevOpsするための解説とチュートリアル |
著者各位へ
内容は須江の独断でまとめておりますので、修正のご要望があればお知らせください。
さいごに
企画したタイミングの都合で、比較対象として当然含めるべきマネージドサービスやディストリビューションが入っていないことが心残りです。
改訂するチャンスがあれば、AKS(Azure)やEKS(AWS)などのマネージド・サービスや、PCR(Pivotal)などのディストリビューションに関する解説も追加して、プロダクション環境でコンテナを使う人にとって有益な内容にアップデートできると嬉しいです。
*1:このへんの補足情報は特典コンテンツに記載しましたので、ご興味があれば翔泳社のサイトからダウンロードしてみてください。 https://www.shoeisha.co.jp/book/detail/9784798155371
OpenShift Origin 3.7でIstioを動かす
このエントリは Kubernetes Advent Calendar 2017 - Qiita の12/8分です。(ちょっとハマってしまって公開が遅くなってすみません。)
2017/11/30にOpenShift3.7がGAになりました。OpenShift3.7はKubernetes1.7ベースなのでようやくIstioが普通に動かせるようになりましたが、デフォルトのセキュリティ設定が厳し目になっていることもあり、適切な権限設定をしてやらないと動きません。そこで、こちらの情報を参考に、minishiftから起動したOpenShift Origin 3.7上でIstioのbookinfoサンプルを動かす手順を紹介します。
blog.openshift.com
注意) OpenShift3.7はまだIstioを正式にサポートしていませんが、将来のバージョンでサポートする予定になっています。現時点ではRed Hatにお問い合わせいただいてもサポートできかねますのでご了承ください。
なお、以下手順はすべてmacOS Sierra(10.12.6)で動作確認しています。
minishiftインストール手順 for macOS
homebrewで入れますので、入っていなければ事前にインストールしておいてください。
xhyve driverインストール
minishiftから起動するVMをxhyveにするために入れておきます。
$ brew install docker-machine-driver-xhyve $ sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve $ sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
minishiftインストール
minishiftの本体です。ローカルマシン上でOpenShift Originを起動するのに使います。
$ brew cask install minishift
詳細: Installing Minishift - Getting Started | Minishift | OpenShift Origin Latest
minishiftの基本的なオペレーション
minishift起動
$ minishift start
minishift VMのIP確認
$ minishift ip
Webコンソールアクセス
$ minishift console $ minishift console —url #url表示のみ
CLIログイン
$ oc login -u developer -p developer #一般ユーザー $ oc login -u admin -p admin #管理ユーザー(cluster-admin)
Istio環境構築
OpenShift Origin 3.7起動 on minishift
$ minishift start --openshift-version v3.7.0 --iso-url centos --cpus 4 --memory 8GB --disk-size 40GB
CentOS7のVM上にOpenShift Origin 3.7を起動します。
CPU/MEM/DISKは環境に合わせて適宜調整してください。MEMはなるべく多めに確保しておいたほうがうよいです。
Istio稼働用環境設定
Istioをデプロイするためのプロジェクトを作成し、必要な権限を設定しておきます。(ほぼザル設定。。。)
$ oc login -u admin -p admin $ oc new-project istio-system $ oc project istio-system $ oc adm policy add-scc-to-user anyuid -z istio-ingress-service-account $ oc adm policy add-scc-to-user privileged -z istio-ingress-service-account $ oc adm policy add-scc-to-user anyuid -z istio-egress-service-account $ oc adm policy add-scc-to-user privileged -z istio-egress-service-account $ oc adm policy add-scc-to-user anyuid -z istio-pilot-service-account $ oc adm policy add-scc-to-user privileged -z istio-pilot-service-account $ oc adm policy add-scc-to-user anyuid -z default $ oc adm policy add-scc-to-user privileged -z default $ oc adm policy add-cluster-role-to-user cluster-admin -z default
Istioインストール
istioctlコマンドおよびサンプルコードをインストールしておきます。
$ curl -L https://git.io/getLatestIstio | sh - $ ISTIO_HOME=$(pwd)/$(ls | grep istio) $ export PATH="$PATH:$ISTIO_HOME/bin" $ cd $ISTIO_HOME $ oc apply -f install/kubernetes/istio.yaml
関連プロダクトのデプロイ
PrometheusやGrafanaなど、モニタリングに利用するプロダクトをデプロイします。
$ oc create -f install/kubernetes/addons/prometheus.yaml $ oc create -f install/kubernetes/addons/grafana.yaml $ oc create -f install/kubernetes/addons/servicegraph.yaml $ oc create -f install/kubernetes/addons/zipkin.yaml $ oc expose svc grafana $ oc expose svc servicegraph $ oc expose svc zipkin
また、この後の作業用に、各プロダクトのURLを環境変数を設定しておきます。
$ SERVICEGRAPH=$(oc get route servicegraph -o jsonpath='{.spec.host}{"\n"}')/dotviz $ GRAFANA=$(oc get route grafana -o jsonpath='{.spec.host}{"\n"}') $ ZIPKIN=$(oc get route zipkin -o jsonpath='{.spec.host}{"\n"}')
bookinfoサンプルアプリケーションのデプロイ
サンプルアプリケーションは $ISTIO_HOME/samples/bookinfo 以下にあります。このエントリでは触れませんが、他にもサンプルがあるので試してみてください。
インストール
$ cd $ISTIO_HOME $ oc apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml) $ oc expose svc productpage
本当はプロジェクトを分けたいところですが、ちと面倒なのでまずはistio-systemプロジェクト内にデプロイしてしまいます。
デプロイ完了まで少し時間がかかるので、以下コマンドを実行して放置しておきましょう。
$ PRODUCTPAGE=$(oc get route productpage -o jsonpath='{.spec.host}{"\n"}') $ watch -n 1 curl -o /dev/null -s -w %{http_code} $PRODUCTPAGE/productpage
200が返ってくるようになったら起動完了です。
起動確認
念のため、すべてのPodがRunning状態になっているか確認します。
$ oc get po NAME READY STATUS RESTARTS AGE details-v1-2818760093-rfsvf 2/2 Running 0 8m grafana-2460282047-df7kt 1/1 Running 0 17m istio-ca-293181461-bkvqw 1/1 Running 0 22m istio-egress-2098918753-xwrzp 1/1 Running 0 22m istio-ingress-3288103321-fnwcd 1/1 Running 0 23m istio-mixer-4195966866-ssbr4 2/2 Running 0 23m istio-pilot-1168925427-c5qq8 1/1 Running 3 23m productpage-v1-1172091313-99m8f 2/2 Running 0 8m prometheus-4086688911-7ztkb 1/1 Running 0 17m ratings-v1-3016823457-cdhn9 2/2 Running 0 8m reviews-v1-3334602649-msgkb 2/2 Running 0 8m reviews-v2-2474208031-t8rfj 2/2 Running 0 8m reviews-v3-471783377-ms9k7 2/2 Running 0 8m servicegraph-4072321759-h7ccm 1/1 Running 0 17m zipkin-3660596538-kmlsd 1/1 Running 0 17m
起動に失敗しているPodがあったら、ログやイベントで原因を確認しましょう。
bookinfoアプリケーションでIstioの機能を確認
単純ルーティング
$ open http://$PRODUCTPAGE
"Normal user"をクリックすると一般ユーザー向けの画面が表示されます。適当にリロードすると、赤星(v3)/黒星(v2)/星無し(v1)の3種類の画面がランダムに表示され、バックエンドのReviewサービスの各バージョンにランダムにルーティングされていることが確認できます。
サービスグラフ
$ open http://$SERVICEGRAPH
サービスの呼び出し経路と、レスポンスタイムなどの統計情報が確認できます。
メトリクスモニタリング
$ open http://$GRAFANA
ダッシュボード"Istio"を選択すると、サービスに関する各種メトリクスを可視化することができます。便利。
分散トレース
$ open http://$ZIPKIN
検索条件を指定して"find trace"を実行すると、サービス呼び出しの履歴やコールツリーを確認できます。
インテリジェントルーティング
細かい条件を指定してルーティングを制御できます。ここではratingsサービスに対して、デフォルトではv1へ、ユーザー"jason"のみv2へルーティングしてみます。
$ oc create -f samples/bookinfo/kube/route-rule-all-v1.yaml $ oc create -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml $ oc get routerule -o yaml
ログインしていない状態では星なし(v1)のページしか見えなくなりますが、jasonでログインすると黒星(v2)が見えます。
ディレイ
httpFaultを利用して意図的な遅延を挿入することができます。障害時の動作をエミュレートするときなどに有用です。
ここではratingsにjasonユーザーのみ7secのdelayを挿入しています。
oc create -f samples/bookinfo/kube/route-rule-ratings-test-delay.yaml
アクセスしてみると、jason以外のユーザーには影響がないことが確認できます。
重み付きバージョンルーティング
サービスのバージョン毎に重みを指定してリクエストを分散できます。
ここでは、reviewsサービスに対するデフォルトのルーティングルールをv1:v3=50:50に変更しています。
$ cat samples/bookinfo/kube/route-rule-reviews-50-v3.yaml apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: reviews-default spec: destination: name: reviews precedence: 1 route: - labels: version: v1 weight: 50 - labels: version: v3 weight: 50 $ oc replace -f samples/bookinfo/kube/route-rule-reviews-50-v3.yaml
クォータ
サービス呼び出しのrate limitを設定できます。memquotaオブジェクトで設定値を指定し、quataオブジェクトでカウント方法を指定、ruleオブジェクトでmemquotaとquataを結びつけます。
$ cat samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml apiVersion: "config.istio.io/v1alpha2" kind: memquota metadata: name: handler namespace: istio-system spec: quotas: - name: requestcount.quota.istio-system maxAmount: 5000 validDuration: 1s # The first matching override is applied. # A requestcount instance is checked against override dimensions. overrides: # The following override applies to 'ratings' when # the source is 'reviews'. - dimensions: destination: ratings source: reviews maxAmount: 1 validDuration: 1s # The following override applies to 'ratings' regardless # of the source. - dimensions: destination: ratings maxAmount: 100 validDuration: 1s --- apiVersion: "config.istio.io/v1alpha2" kind: quota metadata: name: requestcount namespace: istio-system spec: dimensions: source: source.labels["app"] | source.service | "unknown" sourceVersion: source.labels["version"] | "unknown" destination: destination.labels["app"] | destination.service | "unknown" destinationVersion: destination.labels["version"] | "unknown" --- apiVersion: "config.istio.io/v1alpha2" kind: rule metadata: name: quota namespace: istio-system spec: actions: - handler: handler.memquota instances: - requestcount.quota $ oc create -f samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml
Egressルーティング
Istio proxyをインジェクトしたサービス(Istio-enabledなサービス)は、デフォルトではクラスタ外のURLにアクセスできません。外部アクセスが必要な場合は、EgressRuleを設定します。EgressRuleで定義したRouteに対して、RouteRuleのhttp_req_timeoutを指定することも可能。
外向けトラフィックのsource IPをegress routerで指定することや、-includeIPRangesフラグを指定することで istioctl kubectl-inject で注入するenvoy sidecarコンテナのCIDRを指定することもできます。
HBase徹底入門はCloudera Managerユーザーの必読書
仕事でOpenTSDBを使っていることもあり、HBase徹底入門を購入しました。
HBase徹底入門 Hadoopクラスタによる高速データベースの実現
- 作者: 株式会社サイバーエージェント鈴木俊裕,梅田永介,柿島大貴
- 出版社/メーカー: 翔泳社
- 発売日: 2015/01/28
- メディア: 大型本
- この商品を含むブログを見る
- HBaseの概要/アーキテクチャの解説
- HBaseのインストールとアプリケーション開発
- スキーマ設計のポイント
- Cloudera Managerによるクラスタ環境構築
- Cloudera Managerによる運用監視
- トラブルシューティング
などなど、HBaseに限らず、CDH5ベースでHadoopクラスタを運用している人(もしくはこれから運用しようとしている人)にとっては必読の書です。
少なくとも俺得であることは間違いありません。
今までなんとなくHadoopに尻込みしていた人におすすめです。
Lazybonesによるプロジェクトテンプレート管理(1): Lazybones概要/Hello Lazybones
Lazybonesとは?
Lazybonesはプロジェクトテンプレートからプロジェクトのひな形を自動作成するツールです。
Railsのscaffoldや、Mavenのarchetype:generateに近いメージですが、特定のフレームワークやビルドツールに依存しない汎用的なテンプレート管理ツールになっています。(元々はRatpackにプロジェクト新規作成用のコマンドラインツールが提供されていないことを不満に思って作成したそうです。)
とはいえ、Lazybonesのテンプレート作成機能がGradleベースであることや、post-installスクリプトをGroovyで記述することなどから、Gradleプロジェクトのテンプレート管理ツールとして使われることを想定していると考えてよいのではないかと思います。
Lazybones概要
- テンプレートはzip形式のアーカイブで、基本的にはプロジェクトのひな形となるファイル・ディレクトリをアーカイブに含めます。
- テンプレートはBintrayから配布できます(バージョン管理可能)。
- テンプレートには静的なファイルだけでなく、テンプレートエンジンによって生成する動的なファイルを含めることができます。テンプレートエンジンの処理はpost-installスクリプト(Groovyスクリプト)に記述します。
- post-installスクリプトには対話処理を含めることができます。例えば、自動生成するクラスファイルのパッケージ名などをユーザーに入力させることができます。
- サブテンプレート機能によって、プロジェクトの初期生成後にファイルを追加生成できます。(例えば後からコントローラークラスを追加するなど。)
テンプレート配布方法
デフォルトではBintrayの pledbrook/lazybones-templates リポジトリが検索対象となります。
コンフィグレーションでカスタムリポジトリを追加することができるので、例えば自分のBintrayリポジトリを検索対象に追加することも可能です。
また、Bintrayにアップロードせずに、テンプレートのzipファイルをWebサーバーやファイルサーバーにアップロードしておき、URLを直接指定する方法もあります。(いちいちURLを指定するのが面倒なら、コンフィグレーションでURLに別名をつけることもできます。)
テンプレートの開発方法は後日紹介しようと思いますが、興味のある方はこちらを参照してみてください。静的なファイルのみであれば、テンプレート作成はそれほど難しくないです。
Template developers guide · pledbrook/lazybones Wiki · GitHub
インストール方法
2014/12/28現在の最新バージョンは0.8です。
GVMが利用可能であれば、以下でインストールするのが簡単でよいでしょう。
$ gvm install lazybones
バイナリのzipファイルを展開してもよいです。以下からダウンロードして展開し、bin/以下にパスを通してください。
https://bintray.com/pledbrook/lazybones-templates/lazybones/0.8/view/files
使ってみる
以下のコマンドで公式リポジトリのテンプレート一覧を取得できます。
$ lazybones list Available templates in pledbrook/lazybones-templates aem-multimodule-project afterburnerfx afterburnergfx angular-grails asciidoctor-gradle dropwizard gaelyk gradle-plugin gradle-quickstart groovy-app groovy-lib java-basic lazybones-project nebula-plugin ratpack ratpack-lite spring-boot-actuator
試しにSpring Bootのプロジェクトを生成してみましょう。
テンプレートの詳細情報を確認するには「info」コマンドを利用します。
$ lazybones info spring-boot-actuator Fetching package information for 'spring-boot-actuator' from Bintray Name: spring-boot-actuator Latest: 1.0.1.RELEASE Owner: pledbrook Versions: 0.1, 1.0.1.RELEASE, 0.2
提供されているバージョンが確認できましたので、1.0.1.RELEASEからプロジェクトを生成してみます。
プロジェクトの生成には「create」コマンドを利用します。「help <コマンド名>」で各コマンドの詳細が確認できます。
$ lazybones help create Creates a new project from a template. USAGE: create <template> <version>? <dir> where template = The name of the project template to use. version = (optional) The version of the project template to use. Uses the latest version of the template by default. dir = The name of the directory in which to create the project structure. This can be '.' to mean 'in the current directory.' Option Description ------ ----------- -P Add a substitution variable for file filtering. -h, --help Displays usage. --spaces Sets the number of spaces to use for indent in files. --with-git Creates a git repository in the new project.
プロジェクトを生成したいディレクトリに移動し、以下を実行して「mybootapp」ディレクトリ以下にプロジェクトを新規生成します。
$ lazybones create spring-boot-actuator 1.0.1.RELEASE mybootapp
もしくは、以下のようにしてもかまいません。
$ mkdir mybootapp $ cd mybootapp $ lazybones create spring-boot-actuator 1.0.1.RELEASE .
プロジェクトのファイル一式が生成され、最後にREADME.mdの内容が表示されます。
# Spring Boot Actuator Sample You have just created a simple Spring Boot project in Groovy incorporating the Actuator. This includes everything you need to run the application. In this case, that's a simple JSON endpoint. In this project you get: * A Gradle build file * An application class, `SampleApplication`, implementing a single JSON endpoint * A JUnit test case for `SampleApplication` You can build and run this sample using Gradle (>1.6): ``` $ gradle run ``` If you want to run the application outside of Gradle, then first build the JARs and then use the `java` command: ```
生成されたファイル一式は以下のようになっています。
$ tree . ├── README.md ├── build.gradle └── src ├── main │ ├── groovy │ │ └── sample │ │ └── SampleApplication.groovy │ └── resources │ └── application.properties └── test └── groovy └── sample └── SampleApplicationTests.groovy
README.mdに従って実行してみます。(このテンプレートにはGradle Wrapperが含まれていないので、別途Gradleを導入しておく必要があります。)
$ gradle run :compileJava UP-TO-DATE :compileGroovy :processResources :classes :run . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v1.0.1.RELEASE) 2014-12-28 01:05:53.866 INFO 51749 --- [ main] sample.SampleApplication : Starting SampleApplication on nobusue-MacBookPro.local with PID 51749 (/Users/nobusue/work/mybootapp/build/classes/main started by nobusue) 2014-12-28 01:05:53.924 INFO 51749 --- [ main] ationConfigEmbeddedWebApplicationContext : Refreshing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@6ae0286d: startup date [Sun Dec 28 01:05:53 JST 2014]; root of context hierarchy ・・・ [org.springframework.boot:type=Endpoint,name=configurationPropertiesReportEndpoint] 2014-12-28 01:05:57.278 INFO 51749 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080/http 2014-12-28 01:05:57.279 INFO 51749 --- [ main] sample.SampleApplication : Started SampleApplication in 4.282 seconds (JVM running for 4.92) > Building 80% > :run
無事Spring Bootアプリケーションが起動しました。
GroovyでApache Sparkアプリケーションを作る #gadvent
このエントリは G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar 2014 - Qiita の12/20担当分です。
Apache Sparkとは?
Hadoopエコシステムにおける次世代の分散処理基盤として注目されています。インメモリ処理とDAGによるタスクスケジューリングを特徴とし、分散処理に必要な耐障害性を備えています。また、RDDという共通のプログラミングモデルの上で機械学習やストリーミング処理が統一的に扱えるため、複雑なビッグデータ処理を実装するのに有利です。
概要をつかむにはこのへんの資料がよいかと思います。
Groovyから使ってみようと思った動機
公式サイト Apache Spark™ - Lightning-Fast Cluster Computing を見ていただくとわかりますが、Spark自体はScalaで開発されており、アプリケーション開発は Scala / Java / Python で行えるようにAPIが提供されています。(機能の実装状況には差異があり、例えばPythonではSpark1.2でやっとStreamingがサポートされたり、と言った状況です。)
せっかくJavaのAPIがあるのでぜひ使いたいところなのですが、Scala/Pythonに比べて以下のようなビハインドがあります。
- ラムダが使えないのでコードが冗長(Java8を使えばマシにはなりますが、ClouderaがJava8をサポートするまで自分は使えません・・)
- 対話型シェル(REPL)がない
JavaのAPIをGroovyから使うことでこれらの課題に対処できないか試行錯誤していますので、まだ道半ばではありますが現在までの状況をまとめておきます。
コードの簡略化
いくらか成果が上がったので、本エントリで記載します。ただし、Sparkの挙動に起因する癖がありますので注意が必要です。
REPL(Groovy Shell)
こちらはSparkの挙動に起因する癖によって壁にぶつかりました。現時点では解決策が見つかっていません。
具体的にはタスク実行時に以下の例外が発生します。
ERROR org.apache.spark.SparkException: Task not serializable at org.apache.spark.util.ClosureCleaner$.ensureSerializable (ClosureCleaner.scala:166)
GroovyでSpark Wordcountを実行してみる
Quick Start - Spark 1.2.0 Documentation にあるWord CountのJavaサンプルをGroovyで書き換えてみました。
プロジェクト全体はnobusue/groovy-spark-sample · GitHubにあげてあります。
Sparkアプリケーション本体
テキストファイルを読み込んで、指定した単語を含む行数をカウントするだけの簡単なサンプルです。適当なテキストファイルを用意して、「sc.textFile("YOUR_TEXT_FILE_PATH")」のところを置き換えてください。
import org.apache.spark.* import org.apache.spark.api.java.* import org.apache.spark.api.java.function.* public class SparkGroovySample { public static void main(String[] args) { def conf = new SparkConf().setMaster("local[2]").setAppName("WordCount") def sc = new JavaSparkContext(conf) def file = sc.textFile("YOUR_TEXT_FILE_PATH").cache() def filterFunc = new Function<String,Boolean>() { public Boolean call(String s) { return s.contains('spark') }} def filterFunc2 = { it.contains('hadoop') } as Function def countsOfSpark = file.filter(filterFunc).count() def countsOfHadoop = file.filter(filterFunc2).count() println "Count of Spark:${countsOfSpark}, Count of Hadoop:${countsOfHadoop}" } }
例えばSparkのREADME.mdに対して上記を実行すると、
Count of Spark:8, Count of Hadoop:10
みたいになるはずです。
フィルタ関数の定義は、SparkのJava APIでは以下のようにFunctionインターフェースを実装する必要があります。
def filterFunc = new Function<String,Boolean>() { public Boolean call(String s) { return s.contains('spark') }}
Groovyの場合はクロージャから変換することで多少楽ができます。
def filterFunc2 = { it.contains('hadoop') } as Function
注意点
コードを眺めているだけでは分かりづらいのですが、sc.textFile()で読み込んだファイルはRDD(JavaRDD)というオブジェクトに格納されています。
RDDに対する操作はワーカーノードで分散処理されるため、filter()などの操作で利用するオブジェクトはすべてシリアライズしてリモートに送信できなければいけません。上記サンプルをGroovyスクリプトではなくGroovyクラスとして実装しているのはこの条件を満たすためです。(実際に試してみると、Groovyスクリプトとして実装した場合にはfilterFunc()がシリアライザブルでないと判断されて例外が発生します。)
おまけ:ログ設定
SparkはLog4jを使っており、デフォルトではSpark自体の動作に関するログがINFOレベルで大量に出力されます。普段は必要ないので、以下のようにして消しておきましょう。
# Set everything to be logged to the console #log4j.rootCategory=INFO, console log4j.rootCategory=WARN, console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.target=System.err log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n