อธิบาย Crossplane Concept พร้อมตัวอย่าง
Explain Crossplane Concepts with Examples
บทความนี้เป็นเวอร์ชั่นเก่าแล้ว เวอร์ชั่นที่ถูกปรับปรุงใหม่จะถูกย้ายไปที่ Crossplane คืออะไร? อธิบาย Concept ด้วยภาพและตัวอย่าง ครับ
และหลังจากนี้ผมจะเขียนบทความที่ nopnithi.com เป็นหลักครับ
[ENGLISH VERSION IS AT THE BOTTOM]
ก่อนจะเริ่ม…รบกวนกด Like/Follow/Subscribe ให้ผมด้วยนะครับ 🙏
- 💙 Facebook: Nopnithi Tech
- ❤️ YouTube: Nopnithi Tech
- 💙 LinkedIn: Nopnithi (Game) Khaokaew
- 🖤 Medium: Nopnithi Khaokaew (Game)
Crossplane Concept
1. Managed Resources (MRs)
อย่างที่เกริ่นไปตอนต้น Crossplane ได้ช่วยสร้าง CRD (และ custom controller) สำหรับ cloud resource ต่าง ๆ ไว้ให้แล้ว
โดย Crossplane จะเรียก CRD และ custom controller รวมเข้าด้วยกันว่า managed resource (MR) ซึ่งแต่ละ MR จะ map 1–1 กับ cloud resource หนึ่งตัวตามภาพด้านล่าง
ตัวอย่าง Manifest ของ Managed Resource (MR) สำหรับ S3 Bucket
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: nopnithi-crossplane-bucket
spec:
forProvider:
region: ap-southeast-1
tags:
Name: nopnithi-crossplane-bucketซึ่งผมสามารถใช้ kubectlเพื่อสร้าง S3 bucket ขึ้นมาได้แบบนี้
cat <<EOF | kubectl apply -f -
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: nopnithi-crossplane-demo-bucket
spec:
forProvider:
region: ap-southeast-1
tags:
Name: nopnithi-crossplane-demo-bucket
EOFจากนั้น Kubernetes (Crossplane) ก็จะไปสร้าง S3 bucket ให้กับผมและคอยเช็ค status ของ bucket เอาไว้ให้ตลอดเวลา ถ้ามีคนไปแก้ไขหรือลบ bucket มันก็สร้างหรือแก้ไขกลับมาตาม manifest ข้างต้น (เรียกว่าการ reconcile)
2. Providers
เป็นเหมือน plugin ที่ช่วยให้ Crossplane สามารถคุยกับ platform ต่าง ๆ เพื่อสร้าง resource ขึ้นมาบนนั้นได้ (concept คล้ายกับ provider ของ Terraform)
ซึ่งใน provider แต่ละตัวก็จะรวบรวม MR สำหรับ resource ต่าง ๆ ของ platform นั้น ๆ เอาไว้สำหรับใช้สร้างและจัดการ resource เช่น AWS, Azure, GCP หรือ Helm
ตัวอย่าง Manifest ของ Provider และ ProviderConfig สำหรับ AWS
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: upbound-provider-aws
spec:
package: xpkg.upbound.io/upbound/provider-aws:v0.27.0apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-secret
key: creds3. Composite Resources (XRs)
ที่จริงเราสามารถใช้ kubectlกับ manifest ของ MR เพื่อสร้าง resource ขึ้นมาได้โดยตรง แต่โดย practice แล้วเราจะไม่ทำแบบนั้นครับ เพราะนอกจากคนสร้างจะต้องเข้าใจ infrastucture แล้วก็ต้องเข้าใจ Crossplane อีกด้วย (ซึ่งไม่ใช่จุดประสงค์ของการสร้าง self-service platform เลย)
ดังนั้นเราจะรวบรวม MR เป็นก้อนแล้วสร้าง resource ผ่านไอ้เจ้าก้อนนี้ ซึ่งเราจะเรียกมันว่า Composite Resource (XR)
Composite Resource (XR) คือสิ่งที่มัดรวม MR ตั้งแต่ 1 ตัวขึ้นไปเข้าด้วยกันเป็นก้อนเดียว (XR) และสร้าง API ใหม่ที่ง่ายกว่าสำหรับ user เหตุผลก็เพื่อลดความซับซ้อนในการสร้าง infrastructure ลง
โดย XR หนึ่งตัวจะเป็นอะไรก็ได้ เช่น ในตัวอย่างของผมจะเป็น web application ซึ่งประกอบไปด้วย VPC, subnet, network interface และ EC2 instance และผมจะกำหนด API ให้เรียบง่ายที่สุดในการสร้างมัน
นั่นอาจแปลได้ว่าการเตรียม XR ก็คือหน้าที่ของ platform engineer เพื่อสร้าง self-service platform ให้กับ developer ใช้สร้าง resource ต่าง ๆ โดยที่ developer ไม่จำเป็นต้องเข้าใจ infrastructure มากนัก ในขณะเดียวกัน platform team เองก็สามารถคุม standard หรือ policy ได้
ทีนี้การที่ platform engineer จะเตรียม XR ขึ้นมาได้นั้นมีสิ่งที่จะต้องสร้าง 2 อย่าง คือ Composition และ Composite Resource Definition (XRD)
3.1 Composition คือ template ที่ใช้สำหรับสร้าง XR เป็นตัวกำหนดว่า…
- XR ของเราประกอบด้วย MR อะไรบ้าง?
- XR ตัวไหนสามารถใช้ template (composition) นี้ได้?
Tip: หากเทียบกับ Terraform ก็ให้มอง composition เป็นเหมือนกับ Terraform module code ได้เลยครับ
ตัวอย่าง Manifest ของ Composition
อธิบายเฉพาะจุดที่สำคัญในเบื้องต้นก่อนนะครับ
- ภายใน composition จะประกอบด้วย MR หลาย ๆ ตัว
- การกำหนด API version จะต้องตรงกับที่กำหนดไว้ใน XRD
kindผมตั้งเป็น NopnithiWebApp ซึ่งจะตรงกับใน XRDpatchesคือการ transform หรือ map ค่าจาก XR (ในที่นี้คือNopnithiWebApp) ไปใช้กับ MR แต่ละตัว (VPC,Subnet,NetworkInterfaceและInstance)
เมื่อเรียบร้อยแล้ว platform engineer ก็สร้าง composition ขึ้นมาด้วย kubectl
cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: webapp
spec:
compositeTypeRef:
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
resources:
- name: vpc
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
name: nopnithi-crossplane-vpc
labels:
crossplane-demo.nopnithi.com/name: webapp-vpc
spec:
forProvider:
region: ap-southeast-1
cidrBlock: 10.0.0.0/16
tags:
Name: nopnithi-crossplane-vpc
- name: subnet
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
name: nopnithi-crossplane-subnet
labels:
crossplane-demo.nopnithi.com/name: webapp-subnet
spec:
forProvider:
region: ap-southeast-1
availabilityZone: ap-southeast-1a
vpcIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-vpc
cidrBlock: 10.0.0.0/24
tags:
Name: nopnithi-crossplane-subnet
- name: interface
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: NetworkInterface
metadata:
labels:
crossplane-demo.nopnithi.com/name: webapp-interface
name: webapp-interface
spec:
forProvider:
region: ap-southeast-1
subnetIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-subnet
- name: instance
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Instance
metadata:
labels:
crossplane-demo.nopnithi.com/name: webapp-instance
name: webapp-instance
spec:
forProvider:
region: ap-southeast-1
ami: ami-0b94777c7d8bfe7e3
instanceType: t3.small
networkInterface:
- deviceIndex: 0
networkInterfaceIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-interface
creditSpecification:
- cpuCredits: unlimited
patches:
- fromFieldPath: "spec.size"
toFieldPath: "spec.forProvider.instanceType"
transforms:
- type: map
map:
small: t3.small
medium: t3.medium
large: t3.large
- fromFieldPath: "spec.appName"
toFieldPath: "spec.forProvider.tags.Name"
EOFจะได้
composition.apiextensions.crossplane.io/webapp created➜ crossplane-demo kubectl get composition webapp
NAME XR-KIND XR-APIVERSION AGE
webapp NopnithiWebApp custom-api.example.org/v1alpha1 41sซึ่งปกติแล้วเราอาจจะมี composition (template) หลายตัวต่อหนึ่ง XRD (ที่กำลังจะพูดถึงต่อไป) เช่น composition สำหรับ environment ต่าง ๆ อย่าง dev, test หรือ prod อะไรแบบนั้น
3.2 Composite Resource Definition (XRD) คือตัวกำหนด type ของ XR และกำหนด API schema ว่าการจะสร้าง XR ดังกล่าวขึ้นมาจะต้องใช้ API หน้าตาแบบไหน มี property อะไรบ้าง (เรียก field ก็ได้)
Tip: หากเทียบกับ Terraform ก็ให้มอง XRD เป็นเหมือนกับ variable block หลาย ๆ ตัวที่เรา define ไว้ใน Terraform module ก็พอได้ครับ
ตัวอย่าง Manifest ของ Composite Resource Definition (XRD)
kindคือ type ของ XR ที่เรากำหนดขึ้น ในตัวอย่างผมตั้งเป็น NopnithiWebApp- API Schema ผมกำหนดว่าถ้าจะสร้าง XR ตัวนี้จะต้องส่ง property/field เข้ามา 2 ตัว คือ
appNameซึ่งผมจะเอาตัวนี้ไปใช้ใส่ที่ tag:Name ของ EC2 instance ส่วนsizeผมจะเอาไปใช้เป็น instance type ของ EC2 instance
และ platform engineer ก็สร้าง XRD ขึ้นมาด้วย kubectl เช่นเคย
cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: nopnithiwebapps.custom-api.example.org
spec:
group: custom-api.example.org
names:
kind: NopnithiWebApp
plural: nopnithiwebapps
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
appName:
type: string
description: "The name of the application."
size:
type: string
description: "The size of the instance."
enum:
- small
- medium
- large
required:
- size
- appName
claimNames:
kind: CustomNopnithiWebApp
plural: customnopnithiwebapps
EOFจะได้
compositeresourcedefinition.apiextensions.crossplane.io/nopnithiwebapps.custom-api.example.org created➜ crossplane-demo kubectl get xrd nopnithiwebapps.custom-api.example.org
NAME ESTABLISHED OFFERED AGE
nopnithiwebapps.custom-api.example.org True True 2m1sสุดท้ายเมื่อเราจะสร้าง web app stack นี้ขึ้น เราไม่จำเป็นต้องรู้อะไรเกี่ยวกับ VPC หรือ EC2 สักเท่าไร แค่รู้ว่าจะเขียน manifest ยังไงแบบนี้
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
metadata:
name: mywebapp
spec:
size: small
appName: MySmallWebApp
EOFหรือถ้าอยากได้ size ใหญ่สุดก็เปลี่ยนที่ size แบบนี้
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
metadata:
name: mywebapp
spec:
size: large
appName: MyLargeWebApp
EOFจะได้ XR ขึ้นมาชื่อว่า mywebapp ตามที่เรากำหนดไปตอนสร้าง
nopnithiwebapp.custom-api.example.org/mywebapp created➜ crossplane-demo kubectl get composite mywebapp
NAME SYNCED READY COMPOSITION AGE
mywebapp True True webapp 2m7sซึ่ง XR มันก็จะไปสร้าง MR ตาม composition ไงครับ ลองเช็ค MR ดู
➜ crossplane-demo kubectl get vpcs
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-8c7lf True True vpc-0e713e72ed7573c9c 3m8s➜ crossplane-demo kubectl get subnets
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-qtg2c True True subnet-071f6295086c8567d 3m13s➜ crossplane-demo kubectl get networkinterfaces
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-9qftq True True eni-04ae8b011f7e16788 3m19s➜ crossplane-demo kubectl get instances.ec2
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-vjn4f True True i-0dea862b9eee6d9c1 3m30sผมลองเอาหน้า console ของ EC2 มาให้ดูสัก resource นึงแล้วกันเนอะ จะเห็นว่ามันไปสร้าง EC2 instance ให้ (มี VPC, subnet และ ENI ด้วย) และชื่อ instance (tag:Name) ก็มาจาก appName ที่กำหนดใน XRD และถูก map ไปใช้ตาม composition
ทีนี้ผมลอง terminate instance ทิ้งไป แปปเดียว Kubernetes มันก็สร้างกลับมาให้เหมือนเดิมแล้วครับ 😄
4. Claims
Claim (หรือชื่อเต็มคือ Composite Resource Claim — XRC) ถ้าให้แปลเป็นไทยก็คงจะเป็นการอ้างสิทธิ์แหละครับ ซึ่ง claim ถือเป็น interface หลักที่ developer ใช้สำหรับติดต่อกับ Crossplane เพื่อสร้าง XR ขึ้นมา
แม้ว่าการสร้าง XR โดยตรง กับ การสร้าง claim นั้นจะให้ผลลัพธ์ที่เหมือนกัน คือทั้งสองวิธีจะทำให้เราได้ MR หรือก็คือ resource ต่าง ๆ ขึ้นมาแบบรูปข้างล่างนี้
แต่ความต่างก็คือ…
- claim อยู่ใน namespace scope
- ขณะที่ XR อยู่ใน cluster scope
ซึ่ง claim จะช่วยให้เราสามารถแยกแยะ resource ของแต่ละทีม developer ได้ (ที่จริงยังมีเรื่องของการจัดการสิทธิ์ต่าง ๆ ในการสร้าง resource ด้วยแหละ)
ดังนั้นหากเราสร้าง claim เราจะสามารถกำหนด namespace ได้แบบนี้
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: CustomNopnithiWebApp
metadata:
name: claimed-mywebapp
namespace: test
spec:
size: small
appName: MyWebAppTest1
EOFสังเกตว่า kind เปลี่ยนจาก NopnithiWebApp เป็น CustomNopnithiWebApp ตามที่กำหนดไว้ใน XRD แต่อย่างอื่นแทบไม่มีอะไรต่างกันเลย และจะได้
customnopnithiwebapp.custom-api.example.org/claimed-mywebapp created➜ crossplane-demo kubectl get claim -n test
NAME SYNCED READY CONNECTION-SECRET AGE
claimed-mywebapp True True 4mเมื่อสร้าง claim เราก็จะได้ XR (และ MR ทั้งหมด) เหมือนเดิมนั่นแหละครับ และทุกอย่างจะยังคงอยู่ใน cluster scope เช่นกัน เพียงแต่เจ้าตัว claim เองที่จะอยู่ใน namespace ซึ่งตรงนี้ทำให้เราสามารถแยกแยะ resource ของแต่ละทีมได้
สำหรับ concept ของ Crossplane ผมคิดว่าเอาไว้ประมาณนี้แล้วกันครับ คิดว่าน่าจะเพียงพอสำหรับการต่อยอดได้ละ ไว้โอกาสหน้ามาลองทำ hands-on project เกี่ยวกับ Crossplane กันเลยดีกว่า
ถ้าคิดว่าบทความนี้มีประโยชน์ อย่าลืมกด clap และ follow เพื่ออัพเดทเรื่องราวใหม่ ๆ จากผมได้นะครับ
[ENGLISH VERSION]
Continuing from the previous article “What is Crossplane?”, this article proceeds with the concept of Crossplane.
Crossplane Concepts
1. Managed Resources (MRs)
As mentioned in earlier article, Crossplane helps in creating CRDs (and custom controllers) for various cloud resources.
Crossplane refers to the combination of CRDs and custom controllers as managed resources (MR), with each MR mapping 1:1 with a cloud resource.
Managed Resource (MR) manifest for an S3 Bucket:
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: nopnithi-crossplane-bucket
spec:
forProvider:
region: ap-southeast-1
tags:
Name: nopnithi-crossplane-bucketSo I can use kubectl to create an S3 bucket like this:
cat <<EOF | kubectl apply -f -
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: nopnithi-crossplane-demo-bucket
spec:
forProvider:
region: ap-southeast-1
tags:
Name: nopnithi-crossplane-demo-bucket
EOFThen Kubernetes (Crossplane) will create an S3 bucket for me and constantly check the status of the bucket. If someone modifies or deletes the bucket, it will recreate or adjust it according to the above manifest (referred to as reconciliation loop).
2. Providers
These act like plugins that allow Crossplane to communicate with different platforms to create resources on them (a concept similar to Terraform provider).
Each provider collects MRs for different resources of its platform for creating and managing resources such as AWS, Azure, GCP, or Helm.
An example of a Provider and ProviderConfig manifest for AWS:
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: upbound-provider-aws
spec:
package: xpkg.upbound.io/upbound/provider-aws:v0.27.0apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-secret
key: creds3. Composite Resources (XRs)
Actually, we can directly use kubectl with MR’s manifest to create a resource. However, in practice, we usually won’t do this because the user creating the resource needs to understand both the infrastructure and Crossplane (which is not the purpose of creating a self-service platform).
Therefore, we will bundle MRs into one object and create resources via this object, which we will call this object as a Composite Resource (XR).
An XR is something that bundles one or more MRs into a single entity (XR), creating a new API that is simpler for users. The reason being to reduce complexity when creating infrastructure.
A single XR can be anything, such as a web application, which consists of VPC, subnet, network interface, and EC2 instance, and I will determine the simplest possible API to create it.
Preparing XR could be seen as the role of a platform engineer to create a self-service platform for developers to create various resources. Developers don’t need to understand the infrastructure too much while the platform team can control the standards or policies.
To prepare an XR, a platform engineer needs to create two things: a Composition and a Composite Resource Definition (XRD).
3.1 Composition is a template used to create XR and determines…
- What MRs our XR consists of?
- Which XRs can use this template?
Tip: If compared to Terraform, you can think the composition as similar to the Terraform module code.
An example of a Composition manifest:
- A composition consists of several MRs
- The API version must match what is specified in the XRD
- I set
kindas NopnithiWebApp to match the XRD patchesare the transformation or mapping of values from XR (in this case, NopnithiWebApp) for use with each MR (VPC, Subnet, NetworkInterface, and Instance)
Once completed, the platform engineer can create the composition using kubectl.
cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: webapp
spec:
compositeTypeRef:
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
resources:
- name: vpc
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
name: nopnithi-crossplane-vpc
labels:
crossplane-demo.nopnithi.com/name: webapp-vpc
spec:
forProvider:
region: ap-southeast-1
cidrBlock: 10.0.0.0/16
tags:
Name: nopnithi-crossplane-vpc
- name: subnet
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
name: nopnithi-crossplane-subnet
labels:
crossplane-demo.nopnithi.com/name: webapp-subnet
spec:
forProvider:
region: ap-southeast-1
availabilityZone: ap-southeast-1a
vpcIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-vpc
cidrBlock: 10.0.0.0/24
tags:
Name: nopnithi-crossplane-subnet
- name: interface
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: NetworkInterface
metadata:
labels:
crossplane-demo.nopnithi.com/name: webapp-interface
name: webapp-interface
spec:
forProvider:
region: ap-southeast-1
subnetIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-subnet
- name: instance
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Instance
metadata:
labels:
crossplane-demo.nopnithi.com/name: webapp-instance
name: webapp-instance
spec:
forProvider:
region: ap-southeast-1
ami: ami-0b94777c7d8bfe7e3
instanceType: t3.small
networkInterface:
- deviceIndex: 0
networkInterfaceIdSelector:
matchLabels:
crossplane-demo.nopnithi.com/name: webapp-interface
creditSpecification:
- cpuCredits: unlimited
patches:
- fromFieldPath: "spec.size"
toFieldPath: "spec.forProvider.instanceType"
transforms:
- type: map
map:
small: t3.small
medium: t3.medium
large: t3.large
- fromFieldPath: "spec.appName"
toFieldPath: "spec.forProvider.tags.Name"
EOFIt will be like this.
composition.apiextensions.crossplane.io/webapp created➜ crossplane-demo kubectl get composition webapp
NAME XR-KIND XR-APIVERSION AGE
webapp NopnithiWebApp custom-api.example.org/v1alpha1 41sWe may have several compositions (templates) for one XRD, such as compositions for different environments like dev, test, or prod.
3.2 Composite Resource Definition (XRD) is the entity that defines the type of XR and determines the API schema. This schema dictates what API properties (fields) it contains when creating an XR.
Tip: If compared to Terraform, you can see XRD as similar to multiple variable blocks that we define in the Terraform module.
An example of a Composite Resource Definition (XRD) manifest:
kindis the type of XR that we determine. In this example, I set it as NopnithiWebApp.- In the API Schema, I specify that to create this XR, you need to submit two properties:
appName, which I will use to put in the tag:Name of the EC2 instance, andsize, which I will use as the instance type of the EC2 instance.
And the platform engineer can also create the XRD using kubectl.
cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: nopnithiwebapps.custom-api.example.org
spec:
group: custom-api.example.org
names:
kind: NopnithiWebApp
plural: nopnithiwebapps
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
appName:
type: string
description: "The name of the application."
size:
type: string
description: "The size of the instance."
enum:
- small
- medium
- large
required:
- size
- appName
claimNames:
kind: CustomNopnithiWebApp
plural: customnopnithiwebapps
EOFIt will be like this.
compositeresourcedefinition.apiextensions.crossplane.io/nopnithiwebapps.custom-api.example.org created➜ crossplane-demo kubectl get xrd nopnithiwebapps.custom-api.example.org
NAME ESTABLISHED OFFERED AGE
nopnithiwebapps.custom-api.example.org True True 2m1sFinally, when users want to create this web app stack, they don’t need to know much about VPC or EC2. They just need to know how to write a manifest like this.
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
metadata:
name: mywebapp
spec:
size: small
appName: MySmallWebApp
EOFTo get the largest size, you can change the size like this.
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: NopnithiWebApp
metadata:
name: mywebapp
spec:
size: large
appName: MyLargeWebApp
EOFYou’ll get an XR called mywebapp as defined in manifest.
nopnithiwebapp.custom-api.example.org/mywebapp created➜ crossplane-demo kubectl get composite mywebapp
NAME SYNCED READY COMPOSITION AGE
mywebapp True True webapp 2m7sThe XR will then create MRs as per the composition.
➜ crossplane-demo kubectl get vpcs
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-8c7lf True True vpc-0e713e72ed7573c9c 3m8s➜ crossplane-demo kubectl get subnets
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-qtg2c True True subnet-071f6295086c8567d 3m13s➜ crossplane-demo kubectl get networkinterfaces
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-9qftq True True eni-04ae8b011f7e16788 3m19s➜ crossplane-demo kubectl get instances.ec2
NAME READY SYNCED EXTERNAL-NAME AGE
mywebapp-vjn4f True True i-0dea862b9eee6d9c1 3m30sYou can check the MRs to see if the EC2 instance has been created (along with VPC, subnet, and ENI) and the instance name (tag:Name) comes from the appName specified in the XRD and mapped according to the composition.
When I tried to terminate the instance, Kubernetes recreated it exactly as before 😄.
4. Claims
A Claim (or Composite Resource Claim — XRC) is the primary interface that developers use to interact with Crossplane to create an XR.
Even though creating an XR directly and creating a claim result in the same outcome, i.e., both methods lead to the creation of MRs or various resources like the image below.
But the difference is…
- Claims are in the namespace scope
- While XRs are in the cluster scope
Claims help us isolate resources for each developer team (in fact, there are also issues regarding permissions in creating resources).
So, if we create a claim, we can specify a namespace like this:
cat <<EOF | kubectl apply -f -
apiVersion: custom-api.example.org/v1alpha1
kind: CustomNopnithiWebApp
metadata:
name: claimed-mywebapp
namespace: test
spec:
size: small
appName: MyWebAppTest1
EOFNotice that the kind has changed from NopnithiWebApp to CustomNopnithiWebApp as defined in the XRD, but almost everything else remains the same. And we get:
customnopnithiwebapp.custom-api.example.org/claimed-mywebapp created➜ crossplane-demo kubectl get claim -n test
NAME SYNCED READY CONNECTION-SECRET AGE
claimed-mywebapp True True 4mWhen we create a claim, we get an XR (and all MRs) just like before. And everything will still be in the cluster scope, only the claim itself will be in the namespace. This allows us to isolate resources for each team.
For the concept of Crossplane, I think this should be enough for now. I believe it’s sufficient to get started. Next time, let’s try a hands-on project related to Crossplane.
ก่อนจะไป…รบกวนกด Like/Follow/Subscribe ให้ผมด้วยนะครับ 🙏
- 💙 Facebook: Nopnithi Tech
- ❤️ YouTube: Nopnithi Tech
- 💙 LinkedIn: Nopnithi (Game) Khaokaew
- 🖤 Medium: Nopnithi Khaokaew (Game)
