Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1
Halaman ini menjelaskan cara menggunakan KubernetesPodOperator untuk men-deploy Pod Kubernetes dari Cloud Composer ke cluster Google Kubernetes Engine yang merupakan bagian dari lingkungan Cloud Composer Anda.
KubernetesPodOperator meluncurkan Pod Kubernetes di cluster lingkungan Anda. Sebagai perbandingan, operator Google Kubernetes Engine menjalankan Pod Kubernetes di cluster yang ditentukan, yang dapat berupa cluster terpisah yang tidak terkait dengan lingkungan Anda. Anda juga dapat membuat dan menghapus cluster menggunakan operator Google Kubernetes Engine.
KubernetesPodOperator adalah opsi yang tepat jika Anda memerlukan:
- Dependensi Python kustom yang tidak tersedia melalui repositori PyPI publik.
- Dependensi biner yang tidak tersedia di image worker Cloud Composer bawaan.
Sebelum memulai
Jika versi 5.0.0 CNCF Kubernetes Provider digunakan, ikuti petunjuk yang didokumentasikan di bagian CNCF Kubernetes Provider.
Konfigurasi afinitas pod tidak tersedia di Cloud Composer 2. Jika Anda ingin menggunakan afinitas Pod, gunakan operator GKE untuk meluncurkan Pod di cluster yang berbeda.
Tentang KubernetesPodOperator di Cloud Composer 2
Bagian ini menjelaskan cara kerja KubernetesPodOperator di Cloud Composer 2.
Penggunaan resource
Di Cloud Composer 2, cluster lingkungan Anda diskalakan secara otomatis. Beban kerja tambahan yang Anda jalankan menggunakan KubernetesPodOperator diskalakan secara independen dari lingkungan Anda.
Lingkungan Anda tidak terpengaruh oleh peningkatan permintaan resource, tetapi cluster lingkungan Anda akan di-scale up dan di-scale down bergantung pada permintaan resource.
Harga untuk beban kerja tambahan yang Anda jalankan di cluster lingkungan Anda mengikuti model penetapan harga Cloud Composer 2 dan menggunakan SKU Compute Cloud Composer.
Cloud Composer 2 menggunakan cluster Autopilot yang memperkenalkan konsep class komputasi:
Cloud Composer hanya mendukung class komputasi
general-purpose
.Secara default, jika tidak ada class yang dipilih, class
general-purpose
akan diasumsikan saat Anda membuat Pod menggunakan KubernetesPodOperator.Setiap class dikaitkan dengan properti dan batas resource tertentu. Anda dapat membacanya di dokumentasi Autopilot. Misalnya, Pod yang berjalan dalam class
general-purpose
dapat menggunakan memori hingga 110 GiB.
Akses ke resource project
Cloud Composer 2 menggunakan cluster GKE dengan Workload Identity Federation for GKE. Pod yang berjalan di namespace composer-user-workloads
dapat mengakses resource Google Cloud di project Anda tanpa
konfigurasi tambahan. Akun layanan lingkungan Anda
digunakan untuk mengakses resource ini.
Jika Anda ingin menggunakan namespace kustom, akun layanan Kubernetes yang terkait dengan namespace ini harus dipetakan ke akun layanan, untuk mengaktifkan otorisasi identitas layanan untuk permintaan ke Google API dan layanan lainnya. Google Cloud Jika Anda menjalankan Pod di namespace kustom di cluster lingkungan Anda, binding IAM antara Kubernetes dan akun layanan Google Cloud tidak dibuat, dan Pod ini tidak dapat mengakses resource project Google Cloud Anda.
Jika Anda menggunakan namespace kustom dan ingin Pod Anda memiliki akses ke Google Cloud resource, maka ikuti panduan di Workload Identity Federation untuk GKE dan siapkan binding untuk namespace kustom:
- Buat namespace terpisah di cluster lingkungan Anda.
- Buat binding antara Akun Layanan Kubernetes namespace kustom dan akun layanan lingkungan Anda.
- Tambahkan anotasi akun layanan lingkungan Anda ke akun layanan Kubernetes.
- Saat Anda menggunakan KubernetesPodOperator, tentukan namespace dan akun layanan Kubernetes dalam parameter
namespace
danservice_account_name
.
Konfigurasi minimal
Untuk membuat KubernetesPodOperator, hanya parameter name
, image
yang akan digunakan, dan task_id
Pod yang diperlukan. /home/airflow/composer_kube_config
berisi kredensial untuk mengautentikasi ke GKE.
Konfigurasi tambahan
Contoh ini menunjukkan parameter tambahan yang dapat Anda konfigurasi di KubernetesPodOperator.
Lihat referensi berikut untuk mengetahui informasi selengkapnya:
Untuk mengetahui informasi tentang cara menggunakan Secret dan ConfigMaps Kubernetes, lihat Menggunakan Secret dan ConfigMaps Kubernetes.
Untuk mengetahui informasi tentang penggunaan template Jinja dengan KubernetesPodOperator, lihat Menggunakan template Jinja.
Untuk mengetahui informasi tentang parameter KubernetesPodOperator, lihat referensi operator dalam dokumentasi Airflow.
Menggunakan template Jinja
Airflow mendukung template Jinja di DAG.
Anda harus mendeklarasikan parameter Airflow yang diperlukan (task_id
, name
, dan
image
) dengan operator. Seperti yang ditunjukkan dalam contoh berikut, Anda dapat membuat template semua parameter lainnya dengan Jinja, termasuk cmds
, arguments
, env_vars
, dan config_file
.
Parameter env_vars
dalam contoh ditetapkan dari
variabel Airflow bernama my_value
. DAG contoh
mendapatkan nilainya dari variabel template vars
di Airflow. Airflow memiliki lebih banyak variabel yang memberikan akses ke berbagai jenis informasi. Misalnya, Anda dapat menggunakan variabel template conf
untuk mengakses nilai opsi konfigurasi Airflow. Untuk mengetahui informasi selengkapnya dan daftar variabel yang tersedia di Airflow, lihat Referensi template dalam dokumentasi Airflow.
Tanpa mengubah DAG atau membuat variabel env_vars
, tugas
ex-kube-templates
dalam contoh akan gagal karena variabel tidak
ada. Buat variabel ini di UI Airflow atau dengan Google Cloud CLI:
UI Airflow
Buka UI Airflow.
Di toolbar, pilih Admin > Variabel.
Di halaman List Variable, klik Add a new record.
Di halaman Tambahkan Variabel, masukkan informasi berikut:
- Kunci:
my_value
- Val:
example_value
- Kunci:
Klik Simpan.
gcloud
Masukkan perintah berikut:
gcloud composer environments run ENVIRONMENT \
--location LOCATION \
variables set -- \
my_value example_value
Ganti:
ENVIRONMENT
dengan nama lingkungan.LOCATION
dengan region tempat lingkungan berada.
Contoh berikut menunjukkan cara menggunakan template Jinja dengan KubernetesPodOperator:
Menggunakan Secret dan ConfigMaps Kubernetes
Secret Kubernetes adalah objek yang berisi data sensitif. ConfigMap Kubernetes adalah objek yang berisi data tidak rahasia dalam pasangan nilai kunci.
Di Cloud Composer 2, Anda dapat membuat Secret dan ConfigMap menggunakan Google Cloud CLI, API, atau Terraform, lalu mengaksesnya dari KubernetesPodOperator.
Tentang file konfigurasi YAML
Saat membuat Secret atau ConfigMap Kubernetes menggunakan Google Cloud CLI dan API, Anda memberikan file dalam format YAML. File ini harus mengikuti format yang sama seperti yang digunakan oleh Secret dan ConfigMap Kubernetes. Dokumentasi Kubernetes menyediakan banyak contoh kode ConfigMap dan Secret. Untuk memulai, Anda dapat melihat halaman Mendistribusikan Kredensial dengan Aman Menggunakan Secret dan ConfigMaps.
Sama seperti di Secret Kubernetes, gunakan representasi base64 saat Anda menentukan nilai di Secret.
Untuk mengenkode nilai, Anda dapat menggunakan perintah berikut (ini adalah salah satu dari banyak cara untuk mendapatkan nilai yang dienkode base64):
echo "postgresql+psycopg2://root:example-password@127.0.0.1:3306/example-db" -n | base64
Output:
cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==
Dua contoh file YAML berikut digunakan dalam contoh di bagian selanjutnya dalam panduan ini. Contoh file konfigurasi YAML untuk Secret Kubernetes:
apiVersion: v1
kind: Secret
metadata:
name: airflow-secrets
data:
sql_alchemy_conn: cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==
Contoh lain yang menunjukkan cara menyertakan file. Sama seperti contoh sebelumnya, pertama-tama encode konten file (cat ./key.json | base64
), lalu berikan nilai ini dalam file YAML:
apiVersion: v1
kind: Secret
metadata:
name: service-account
data:
service-account.json: |
ewogICJ0eXBl...mdzZXJ2aWNlYWNjb3VudC5jb20iCn0K
Contoh file konfigurasi YAML untuk ConfigMap. Anda tidak perlu menggunakan representasi base64 dalam ConfigMaps:
apiVersion: v1
kind: ConfigMap
metadata:
name: example-configmap
data:
example_key: example_value
Mengelola Secret Kubernetes
Di Cloud Composer 2, Anda membuat Secret menggunakan Google Cloud CLI dan kubectl
:
Dapatkan informasi tentang cluster lingkungan Anda:
Jalankan perintah berikut:
gcloud composer environments describe ENVIRONMENT \ --location LOCATION \ --format="value(config.gkeCluster)"
Ganti:
ENVIRONMENT
dengan nama lingkungan Anda.LOCATION
dengan region tempat lingkungan Cloud Composer berada.
Output perintah ini menggunakan format berikut:
projects/<your-project-id>/locations/<location-of-composer-env>/clusters/<your-cluster-id>
.Untuk mendapatkan ID cluster GKE, salin output setelah
/clusters/
(berakhir dengan-gke
).
Hubungkan ke cluster GKE Anda dengan perintah berikut:
gcloud container clusters get-credentials CLUSTER_ID \ --project PROJECT \ --region LOCATION
Ganti kode berikut:
CLUSTER_ID
: ID cluster lingkungan.PROJECT_ID
: Project ID.LOCATION
: region tempat lingkungan berada.
Buat Secret Kubernetes:
Perintah berikut menunjukkan dua pendekatan berbeda untuk membuat Secret Kubernetes. Pendekatan
--from-literal
menggunakan key-value pair. Pendekatan--from-file
menggunakan konten file.Untuk membuat Secret Kubernetes dengan memberikan pasangan nilai kunci, jalankan perintah berikut. Contoh ini membuat Secret bernama
airflow-secrets
yang memiliki kolomsql_alchemy_conn
dengan nilaitest_value
.kubectl create secret generic airflow-secrets \ --from-literal sql_alchemy_conn=test_value -n composer-user-workloads
Untuk membuat Secret Kubernetes dengan memberikan konten file, jalankan perintah berikut. Contoh ini membuat Secret bernama
service-account
yang memiliki kolomservice-account.json
dengan nilai yang diambil dari konten file./key.json
lokal.kubectl create secret generic service-account \ --from-file service-account.json=./key.json -n composer-user-workloads
Menggunakan Secret Kubernetes di DAG Anda
Contoh ini menunjukkan dua cara menggunakan Secret Kubernetes: sebagai variabel lingkungan, dan sebagai volume yang di-mount oleh Pod.
Secret pertama, airflow-secrets
, ditetapkan
ke variabel lingkungan Kubernetes bernama SQL_CONN
(bukan
variabel lingkungan Airflow atau Cloud Composer).
Secret kedua, service-account
, memasang service-account.json
, file dengan token akun layanan, ke /var/secrets/google
.
Berikut tampilan objek Secret:
Nama Kubernetes Secret pertama ditentukan dalam variabel secret_env
.
Secret ini diberi nama airflow-secrets
. Parameter deploy_type
menentukan
bahwa parameter tersebut harus diekspos sebagai variabel lingkungan. Nama variabel lingkungannya adalah SQL_CONN
, seperti yang ditentukan dalam parameter deploy_target
. Terakhir, nilai variabel lingkungan SQL_CONN
ditetapkan ke nilai kunci sql_alchemy_conn
.
Nama Secret Kubernetes kedua ditentukan dalam variabel secret_volume
. Secret ini diberi nama service-account
. Objek ini diekspos sebagai
volume, seperti yang ditentukan dalam parameter deploy_type
. Jalur file yang akan di-mount, deploy_target
, adalah /var/secrets/google
. Terakhir, key
dari
Secret yang disimpan di deploy_target
adalah service-account.json
.
Berikut tampilan konfigurasi operator:
Informasi tentang Penyedia Kubernetes CNCF
KubernetesPodOperator diimplementasikan di penyedia
apache-airflow-providers-cncf-kubernetes
.
Untuk catatan rilis mendetail penyedia CNCF Kubernetes, lihat situs Penyedia CNCF Kubernetes.
Versi 6.0.0
Pada paket CNCF Kubernetes Provider versi 6.0.0, koneksi kubernetes_default
digunakan secara default di KubernetesPodOperator.
Jika Anda menentukan koneksi kustom di versi 5.0.0, koneksi kustom ini masih digunakan oleh operator. Untuk beralih kembali menggunakan koneksi kubernetes_default
, Anda mungkin perlu menyesuaikan DAG Anda.
Versi 5.0.0
Versi ini memperkenalkan beberapa perubahan yang tidak kompatibel dengan versi lama dibandingkan dengan versi 4.4.0. Yang paling penting terkait dengan koneksi kubernetes_default
yang tidak digunakan di versi 5.0.0.
- Koneksi
kubernetes_default
perlu diubah. Jalur config Kubernetes harus disetel ke/home/airflow/composer_kube_config
(seperti yang ditunjukkan pada gambar berikut). Sebagai alternatif,config_file
harus ditambahkan ke konfigurasi KubernetesPodOperator (seperti yang ditunjukkan dalam contoh kode berikut).

- Ubah kode tugas menggunakan KubernetesPodOperator dengan cara berikut:
KubernetesPodOperator(
# config_file parameter - can be skipped if connection contains this setting
config_file="/home/airflow/composer_kube_config",
# definition of connection to be used by the operator
kubernetes_conn_id='kubernetes_default',
...
)
Untuk mengetahui informasi selengkapnya tentang Versi 5.0.0, lihat Catatan Rilis Penyedia Kubernetes CNCF.
Pemecahan masalah
Bagian ini memberikan saran untuk memecahkan masalah umum KubernetesPodOperator:
Melihat log
Saat memecahkan masalah, Anda dapat memeriksa log dalam urutan berikut:
Log Tugas Airflow:
Di konsol Google Cloud , buka halaman Environments.
Dalam daftar lingkungan, klik nama lingkungan Anda. Halaman Environment details akan terbuka.
Buka tab DAG.
Klik nama DAG, lalu klik eksekusi DAG untuk melihat detail dan log.
Log penjadwal Airflow:
Buka halaman Detail lingkungan.
Buka tab Log.
Periksa log penjadwal Airflow.
Log pod di konsol Google Cloud , di bagian workload GKE. Log ini mencakup file YAML definisi Pod, peristiwa Pod, dan detail Pod.
Kode pengembalian bukan nol
Saat menggunakan KubernetesPodOperator (dan GKEStartPodOperator), kode yang ditampilkan dari titik entri container menentukan apakah tugas dianggap berhasil atau tidak. Kode kembalian selain nol menunjukkan kegagalan.
Pola umum adalah menjalankan skrip shell sebagai titik entri container untuk mengelompokkan beberapa operasi dalam container.
Jika Anda menulis skrip seperti itu, sebaiknya sertakan perintah
set -e
di bagian atas skrip sehingga perintah yang gagal dalam skrip
menghentikan skrip dan menyebarkan kegagalan ke instance tugas Airflow.
Waktu tunggu pod
Waktu tunggu default untuk KubernetesPodOperator adalah 120 detik, yang
dapat menyebabkan waktu tunggu habis sebelum image yang lebih besar didownload. Anda dapat memperpanjang waktu tunggu dengan mengubah parameter startup_timeout_seconds
saat membuat KubernetesPodOperator.
Jika Pod mengalami waktu tunggu habis, log khusus tugas tersedia di UI Airflow. Contoh:
Executing <Task(KubernetesPodOperator): ex-all-configs> on 2018-07-23 19:06:58.133811
Running: ['bash', '-c', u'airflow run kubernetes-pod-example ex-all-configs 2018-07-23T19:06:58.133811 --job_id 726 --raw -sd DAGS_FOLDER/kubernetes_pod_operator_sample.py']
Event: pod-name-9a8e9d06 had an event of type Pending
...
...
Event: pod-name-9a8e9d06 had an event of type Pending
Traceback (most recent call last):
File "/usr/local/bin/airflow", line 27, in <module>
args.func(args)
File "/usr/local/lib/python2.7/site-packages/airflow/bin/cli.py", line 392, in run
pool=args.pool,
File "/usr/local/lib/python2.7/site-packages/airflow/utils/db.py", line 50, in wrapper
result = func(*args, **kwargs)
File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1492, in _run_raw_task
result = task_copy.execute(context=context)
File "/usr/local/lib/python2.7/site-packages/airflow/contrib/operators/kubernetes_pod_operator.py", line 123, in execute
raise AirflowException('Pod Launching failed: {error}'.format(error=ex))
airflow.exceptions.AirflowException: Pod Launching failed: Pod took too long to start
Waktu Tunggu Pod juga dapat terjadi saat Akun Layanan Cloud Composer tidak memiliki izin IAM yang diperlukan untuk melakukan tugas yang sedang dikerjakan. Untuk memverifikasi hal ini, lihat error tingkat Pod menggunakan Dasbor GKE untuk melihat log Workload tertentu, atau gunakan Cloud Logging.
Gagal membuat koneksi baru
Upgrade otomatis diaktifkan secara default di cluster GKE. Jika node pool berada di cluster yang sedang diupgrade, Anda mungkin melihat error berikut:
<Task(KubernetesPodOperator): gke-upgrade> Failed to establish a new
connection: [Errno 111] Connection refused
Untuk memeriksa apakah cluster Anda sedang diupgrade, di konsol Google Cloud , buka halaman Kubernetes clusters dan cari ikon pemuatan di samping nama cluster lingkungan Anda.