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製品の基盤となる仕組みなので要注目です。

このリリースについて

このリリースは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)

OLMクラスタ管理者がOperatorのインストールやアップグレード、アクセス管理などを行うのをサポートする

  • おすすめOperatorのカタログと、その他Operatorをクラスタにロードする機能
  • Operatorを新しいバージョンにローリングアップデート
  • role-based access control(RBAC)により特定のチームに特定のOperatorの利用を許可

詳細はドキュメントを参照
https://docs.openshift.com/container-platform/3.11/install_config/installing-operator-framework.html#installing-operator-framework

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

認証ありレジストリのサポート

Red Hat Container Catalogが registry.access.redhat.com から registry.redhat.io に移動し、コンテナイメージの取得時に認証が必要になった。
OCP3.11では認証ありレジストリのサポートが追加され、Brokerはレジストリの認証情報としてデフォルトでクラスタワイドの設定値(inventory fileのoreg_auth_userとoreg_auth_passwordで指定)を利用する。

Service CatalogがNamespace毎のBrokerに対応

Brokerのインストール時にkindとしてServiceBroker(Namespace毎)もしくはClusterServiceBroker(クラスタ全体)が指定可能になった。
Service Catalogは対応するBrokerによってNamespace指定ないしクラスタ全体のスコープで動作する。

インストールとアップグレード

アップグレード時の証明書有効期限チェック

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]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

[TP]テナント駆動のストレージスナップショット

VolumeSnapshotリソースを利用して、PVCにアタッチされたPVのスナップショットを取得できる。
クラスタ管理者がexternal provisionerと、それに対応するStorageClassを登録しておく必要がある。
AWS-EBS, GCE-PD, hostPathに対応しているが、テストされているのはAWS-EBSとhostPathのみ。

スケーラビリティ関連

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がフルサポートになり、デフォルトでクラスタにデプロイされる。

  • Prometheusが収集したcluster metricsに対するクエリーとプロット
  • プリパッケージのアラート通知により、修正アクションや問題判別が可能に
  • etcd, クラスタステータス, およびその他多くのクラスタヘルスを確認するためのプリパッケージのGrafanaダッシュボード

詳細はドキュメントを参照
https://docs.openshift.com/container-platform/3.11/install_config/prometheus_cluster_monitoring.html#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

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コマンドしかダウンロードできなかった。これから対応?

レジストリ

Red Hatレジストリへの接続設定

Red Hat Container Catalogが registry.access.redhat.com から registry.redhat.io に移動し、認証が必要になったので注意。
https://docs.openshift.com/container-platform/3.11/install_config/configuring_red_hat_registry.html#install-config-configuring-red-hat-registry

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

ネットワーク

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を付与

VXLANのポートが変更可能に

OCP SDNのオーバーレイVXLANポートがデフォルトの4789から変更可能に。
VMware NSX SDN(6.2.3以上)でポートが8472から4789に変更になったため、ポートコンフリクトを回避する必要あり。

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オブジェクトの管理

以下のオブジェクトの参照/編集/削除が可能

  • ネットワーク
  • ストレージ
    • PV / PVC
    • StorageClass
  • 管理
    • Project / Namespace
    • Node
    • Role / RoleBinding
    • CustomResourceDefinition(CRD)
アクセスコントロール管理

クラスタのRBACのビジュアル管理が可能に

  • 特定のロールを持つユーザやサービスアカウントの検索
  • クラスタ全体およびネームスペース毎のバインディング
  • Roleのverbとobjectの可視化
クラスタワイドのイベントストリーム

権限のある全てのProject/Namespaceのイベントをフィルタリングして参照可能

セキュリティ

[TP]コンテナ間でのPID Namespaceの共有の制御
[TP]Microsoft Windows上でのSSPI接続サポート

ドメイン認証済みのWindowsマシンからのocコマンドによるシングルサインオン

マイクロサービス

[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(プロダクションサポート)になったり、ストレージ関連でいくつか意欲的な機能拡張が入ったりしていますので、自分用の備忘も兼ねてまとめておきます。

稼働環境

ベース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に追加されている。
    • master-restart [etcd | api | controllers]
    • master-logs [etcd | api | controllers]
    • master-exec [etcd | api | controllers]
  • Atomic Hostはdeprecatedになった。3.11まではサポートされるが、4.0でremoveされる予定。

ストレージ

  • [TP]OpenStack ManilaがPVとして利用可能になった
  • [TP]glusterFSバックエンドのPVのリサイズが可能になった
  • [TP]CSI(Container Storage Interface)に対応
  • [TP]ローカルエフェメラルストレージの保護機能を追加(デフォルトでは無効化されている)
  • [TP]テナント駆動のストレージスナップショット取得とリストアが可能に

スケール(パフォーマンス関連)

  • バイスプラグインがGAに
  • CPUマネージャがGAになり、CPUアサインの緻密な制御が可能に
  • バイスマネージャがGAになり、特定デバイス(GPUなど)の緻密な制御が可能に
  • Huge PageがGAになり、大容量のメモリを必要とするPodにHuge Pageのアサインが可能に

ネットワーク

  • Routeの同時接続数の制限が可能に(アノテーションhaproxy.router.openshift.io/pod-concurrent-connectionsが追加)
  • KubernetesIngressオブジェクトをサポート(Ingressの作成と同期してRouteを自動生成)
  • Egress RouterでDNS名による設定が可能に
  • Serviceネットワークのアドレスレンジ拡張が可能に
  • [TP]KuryrによりOpenStackとOpenShiftのネットワークの統合をより緊密に(OpenStack側のテナントの利用など)

Master/Node

  • [TP]Deschedulerが追加され、ノード追加時のPodの偏りなどを補正することが可能に
  • [TP]Node Problem Detectorが追加され、ノードレベルの障害発生時にPodのスケジューリングを抑止することなどが可能に。カスタムプラグインによる拡張も可能。
  • Nodeの構成方法が変更され、configmapがマスター情報となった(各Nodeのnode-config.yamlに自動的に反映される)
  • [TP]デーモンレスのコンテナ管理CLIとしてPodmanが追加された

メトリクスとロギング

  • [TP]Prometheusは引き続きTPだが、バージョンが更新され、node-exporterが追加された
  • [TP]Fluentdのsyslog output plug-inのサポート

開発者向け機能

  • Service Catalog CLI(svcat)の追加
  • [TP]CLIプラグイン(ocコマンドの拡張)のサポート
  • Registryのメトリクスのエンドポイント公開(OpenShift認証統合)

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で作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

Kindle

少し遅れて刊行されましたが、ちゃんとリフロー対応になっていました。素晴らしい!

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

書籍の位置づけ

まえがきにも記載がありますが、自分としては企画段階で「プロダクション環境でコンテナを使う人のためのカタログ」ということを念頭に置いていました。そのため、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

ocコマンドインストール

OpenShiftのCLIです。(Kubernetesでのkubectl相当)

$ brew install openshift-cli

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サービスの各バージョンにランダムにルーティングされていることが確認できます。
f:id:nobusue:20171211053151p:plain
f:id:nobusue:20171211053224p:plain

サービスグラフ

$ open http://$SERVICEGRAPH

サービスの呼び出し経路と、レスポンスタイムなどの統計情報が確認できます。
f:id:nobusue:20171211053257p:plain

メトリクスモニタリング

$ open http://$GRAFANA

ダッシュボード"Istio"を選択すると、サービスに関する各種メトリクスを可視化することができます。便利。
f:id:nobusue:20171211053345p:plain

分散トレース

$ open http://$ZIPKIN

検索条件を指定して"find trace"を実行すると、サービス呼び出しの履歴やコールツリーを確認できます。
f:id:nobusue:20171211053410p:plain

インテリジェントルーティング

細かい条件を指定してルーティングを制御できます。ここでは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以外のユーザーには影響がないことが確認できます。

タイムアウト

httpReqTimeoutを指定することで、サービス呼び出しのタイムアウトを設定することができます。

重み付きバージョンルーティング

サービスのバージョン毎に重みを指定してリクエストを分散できます。
ここでは、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を指定することもできます。

アクセスコントロール

ルールによる明示的なアクセス拒否や、ホワイトリスト方式によるアクセス拒否ができます。

まとめ

マイクロサービスをプロダクション運用する場合、従来であればNetflix OSSなどがよく使われていましたが、「Javaに限定される」「アプリケーションコードに非機能要件が入り込む」という課題がありました。
Istioのようなサービスメッシュ層を設けることで、実装言語によらずに、マイクロサービスの運用や問題判別に必要な機能を外付けすることができるようになります。特にKubernetesのPodとの相性が良いので、今後はIstio+Kubernetesの組み合わせでマイクロサービスをデプロイすることが多くなりそうです。

HBase徹底入門はCloudera Managerユーザーの必読書

仕事でOpenTSDBを使っていることもあり、HBase徹底入門を購入しました。

HBase徹底入門 Hadoopクラスタによる高速データベースの実現

HBase徹底入門 Hadoopクラスタによる高速データベースの実現

まだざっとしか読んでいませんが、

  • HBaseの概要/アーキテクチャの解説
  • HBaseのインストールとアプリケーション開発
  • スキーマ設計のポイント
  • Cloudera Managerによるクラスタ環境構築
  • Cloudera Managerによる運用監視
  • トラブルシューティング

などなど、HBaseに限らず、CDH5ベースでHadoopクラスタを運用している人(もしくはこれから運用しようとしている人)にとっては必読の書です。
少なくとも俺得であることは間違いありません。

今までなんとなくHadoopに尻込みしていた人におすすめです。

Lazybonesによるプロジェクトテンプレート管理(1): Lazybones概要/Hello Lazybones

Lazybonesとは?

Lazybonesはプロジェクトテンプレートからプロジェクトのひな形を自動作成するツールです。

Railsのscaffoldや、Mavenarchetype: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アプリケーションが起動しました。

まとめ

spring-boot-actuatorテンプレートではアプリケーションのクラス名などは決め打ちになっていますが、post-installスクリプトを追加すればユーザーの入力に従ってクラス名を変更することなどが可能です。そのため、GitHubなどでテンプレートプロジェクトを公開するより、より使いやすい形で提供することができそうです。
なぜか日本語情報の少ないLazybonesですが、シンプルながら要所をおさえた作りになっており、なかなか使えそうです。
次回以降、テンプレート作成と公開について紹介していく予定です。

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がサポートされたり、と言った状況です。)
せっかくJavaAPIがあるのでぜひ使いたいところなのですが、Scala/Pythonに比べて以下のようなビハインドがあります。

  • ラムダが使えないのでコードが冗長(Java8を使えばマシにはなりますが、ClouderaがJava8をサポートするまで自分は使えません・・)
  • 対話型シェル(REPL)がない

JavaAPIを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

まとめ

素直にScalaPythonを勉強した方が楽かもしれませんが、それぞれ一長一短があるのでJava(Groovy)で使う方法も引き続き試行錯誤していきます。