paint-brush
কুমা মেশেস হেড-অন - আপনার যা জানা দরকারদ্বারা@jesperancinha
707 পড়া
707 পড়া

কুমা মেশেস হেড-অন - আপনার যা জানা দরকার

দ্বারা João Esperancinha27m2024/04/13
Read on Terminal Reader

অতিদীর্ঘ; পড়তে

দ্রুত কুমা শেখা শুরু করার জন্য, আমাদের সবচেয়ে গুরুত্বপূর্ণ জিনিসগুলির মধ্যে একটি হল ক্লাস্টার। তারপরে, কুবারনেটেস (ওরফে k8s) এ আমাদের পডের অবস্থা জানতে আমাদের একটি কমান্ডের প্রয়োজন
featured image - কুমা মেশেস হেড-অন - আপনার যা জানা দরকার
João Esperancinha HackerNoon profile picture
0-item
1-item

কুমা মেশেস হেড-অন - একটি শিক্ষানবিস গাইড

দ্রুত Kuma শেখা শুরু করার জন্য, আমাদের সবচেয়ে গুরুত্বপূর্ণ জিনিসগুলির মধ্যে একটি হল ক্লাস্টার। তারপর, আমাদের কুবারনেটেস (ওরফে k8s ) এ আমাদের পডের অবস্থা জানতে একটি কমান্ডের প্রয়োজন, আমাদের এছাড়াও Kuma ইনস্টল করতে সক্ষম হতে হবে, এবং অবশেষে, আমাদের কিছু Kuma কমান্ড ইস্যু করতে সক্ষম হতে হবে।


এটি বলার একটি দীর্ঘ পথ যে Kuma জন্য সবকিছু প্রস্তুত করার জন্য আমাদের 4টি প্রয়োজনীয় কমান্ড ইনস্টল করতে হবে। এই কমান্ডগুলি হল:

  • kind - এটি ডকারে কুবারনেটস নামেও পরিচিত। এটি এমন একটি কমান্ড যা শুধুমাত্র kubectl দিয়ে স্টাফ তৈরির ওজন বাড়ায়।


  • kubectl - সম্ভবত এই তালিকায় সবচেয়ে প্রত্যাশিত একটি, যদি আপনি ইতিমধ্যে k8s এর সাথে কাজ করতে অভ্যস্ত হয়ে থাকেন। এইভাবে আমরা আমাদের k8s ক্লাস্টারে কমান্ড ইস্যু করতে পারি।


  • helm - হেলম আমাদের কিছু খুব সহজ স্ক্রিপ্ট চালানোর অনুমতি দেয় যা অন্যদের মধ্যে, Kuma কন্ট্রোল প্লেন ইনস্টল করার অনুমতি দেয়।


  • kumactl - আমরা এই নির্দেশিকায় প্রায়শই এই কমান্ডটি ব্যবহার করব না, তবে এটি কীভাবে ব্যবহার করবেন সে সম্পর্কে সচেতন হওয়া গুরুত্বপূর্ণ।


এই নির্দেশিকাটি আপনাকে Ubuntu কীভাবে এটি করতে হবে তা জানাবে। এই সব একটি Ubuntu সিস্টেমে পরীক্ষা করা হয়েছে. আপনি যদি Mac-OS বা Windows বা আপনার কাছে থাকা অন্য কোন অপারেটিং সিস্টেমে এটি কীভাবে ইনস্টল করবেন সে সম্পর্কে একটি নির্দেশিকা পেতে আগ্রহী হন, দয়া করে আমার YouTube চ্যানেল JESPROTECH সম্প্রদায়ে আমাকে একটি চিৎকার দিন।


I. কমান্ড ইনস্টল করা


ছবির বর্ণনা


ডকারে কাইন্ড ( k8s )

ধরনের ইনস্টল করার জন্য, আমাদের এই কমান্ডগুলি জারি করতে হবে:

 [ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin/kind


এটি লক্ষ্য করা গুরুত্বপূর্ণ যে কমান্ড kind আপনার /usr/local/bin/kind এ ইনস্টল করা হবে। এমনকি লিনাক্স ডিস্ট্রিবিউশনের মধ্যেও এটি সিস্টেম প্রতি পরিবর্তিত হতে পারে।


সার্টিফিকেট এবং GPG কী ইনস্টল করা হচ্ছে

helm এবং kubectl উভয় কমান্ডই নির্দিষ্ট GPG কীগুলির উপস্থিতি সহ ইনস্টল করা প্রয়োজন। এইভাবে আমরা তাদের আমাদের লিনাক্স apt ডিস্ট্রিবিউশনের স্থানীয় সংগ্রহস্থলে যুক্ত করতে পারি:

 sudo apt-get install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update



kubectl

পূর্ববর্তী ধাপটি সম্পূর্ণ হয়ে গেলে Kubectl এর ইনস্টলেশন খুব সহজ:

 sudo apt-get install -y kubelet kubeadm kubectl


kubelet , kubeadm , এবং kubectl কমান্ডগুলি বাধ্যতামূলক নয়, তবে সেগুলি ইনস্টল করা একটি ভাল ধারণা।


শিরস্ত্রাণ

আপনি ইতিমধ্যে অনুমান করতে পারেন, helm এখন ইনস্টল করা খুব সহজ:

 sudo apt-get install -y helm

কুমা

Kuma ইনস্টলেশন কিছুটা কষ্টকর হতে পারে কারণ এতে একটি ম্যানুয়াল পদক্ষেপ জড়িত, তবে প্রথমে আমাদের নির্ভরতা ডাউনলোড করতে হবে:

 cd ~ || exit; curl -L https://kuma.io/installer.sh | VERSION=2.6.1 sh -


এই কমান্ডটি জারি করার আগে আপনার HOME ফোল্ডারে থাকতে ভুলবেন না। Kuma এমন জায়গায় ইনস্টল করা গুরুত্বপূর্ণ যেখানে এটি সহজে অ্যাক্সেসযোগ্য এবং সহজে দেখা যায়, উদাহরণস্বরূপ, আমরা যদি এটি অপসারণের সিদ্ধান্ত নিই।


একবার আমরা এটি সম্পন্ন করার পরে, আমাদের PATH-এ bin ফোল্ডারটি যুক্ত করাও অত্যন্ত গুরুত্বপূর্ণ:

 export PATH=~/kuma-2.6.1/bin:$PATH;


আপনার স্টার-আপ স্ক্রিপ্টের শেষের দিকে বা যেকোনো জায়গায় এই লাইনটি যোগ করা এই প্রক্রিয়াটিকে সহজ করে তুলবে। আপনার স্টার্টআপ স্ক্রিপ্ট এই .bashrc , .zshrc , .profile এবং সম্ভবত অন্য ফর্ম নিতে পারে।


k9s

k9s ইনস্টল করা অন্যান্য অ্যাপ্লিকেশন থেকে বেশ আলাদা। এই ক্ষেত্রে, আমরা Linux জন্য pacman বা brew ব্যবহার করতে পারি। আমি বেশিরভাগই Mac-OS জন্য brew ব্যবহার করেছি এবং লিনাক্সে এটির খুব কমই প্রয়োজন ছিল, তবে এই ক্ষেত্রে, এটি খুব বেশি প্রয়োজন, এবং তাই প্রথমে এটি করার জন্য, আমাদের এভাবে ব্রু ইনস্টল করতে হবে:

 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"


ব্রু ইনস্টলেশন সম্পন্ন হলে, আমাদের যা করতে হবে তা হল k9s (" kanines ") ইনস্টল করা:

 brew install derailed/k9s/k9s


একটি বিষয় যা বিবেচনায় নেওয়া গুরুত্বপূর্ণ, এবং আপনি সম্ভবত এটি লক্ষ্য করবেন একবার আপনি প্রথমবার k9s ইনস্টল এবং চালানো শুরু করলে, এটি হল যে k9s ক্র্যাশ হয়ে যাবে যদি এটি পর্যবেক্ষণ করছে এমন একটি ক্লাস্টার সরানো এবং/অথবা যোগ করা হয়।


২. ক্লাস্টার তৈরি করা

 kind create cluster --name=wlsm-mesh-zone kubectl cluster-info --context kind-wlsm-mesh-zone


প্রথম কমান্ডটি wlsm-mesh-zone নামে একটি ক্লাস্টার তৈরি করে। এটি শুধুমাত্র একটি ক্লাস্টার যা আমরা কুমা ইনস্টল করতে ব্যবহার করব। দ্বিতীয় কমান্ডটি ক্লাস্টারের স্থিতি পরীক্ষা করতে ব্যবহৃত হয়।


III. একটি স্থানীয় ডকার রেজিস্ট্রি তৈরি করা

আমি আগে উল্লেখ করেছি, আমরা খুব সহজেই একটি ডকার রেজিস্ট্রি তৈরি করতে পারি। এটি তৈরি করা যতটা সহজ মনে হতে পারে, এটি করার জন্য স্ক্রিপ্টটি মুষ্টিমেয়। সুতরাং, তাদের ওয়েবসাইটে ইতিমধ্যে উপলব্ধ যে ধরনের অনুলিপি এবং পেস্ট করা সবচেয়ে ভাল জিনিস। এখানে, আমরা এই স্ক্রিপ্টটি ডাউনলোড করতে পারি:

 #!/bin/sh # Original Source # https://creativecommons.org/licenses/by/4.0/ # https://kind.sigs.k8s.io/docs/user/local-registry/ set -o errexit # 1. Create registry container unless it already exists reg_name='kind-registry' reg_port='5001' if [ "$(docker inspect -f '{{.State.Running}}' "${reg_name}" 2>/dev/null || true)" != 'true' ]; then docker run \ -d --restart=always -p "127.0.0.1:${reg_port}:5000" --network bridge --name "${reg_name}" \ registry:2 fi # 2. Create kind cluster with containerd registry config dir enabled # TODO: kind will eventually enable this by default and this patch will # be unnecessary. # # See: # https://github.com/kubernetes-sigs/kind/issues/2875 # https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration # See: https://github.com/containerd/containerd/blob/main/docs/hosts.md cat <<EOF | kind create cluster --config=- kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 containerdConfigPatches: - |- [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d" EOF # 3. Add the registry config to the nodes # # This is necessary because localhost resolves to loopback addresses that are # network-namespace local. # In other words: localhost in the container is not localhost on the host. # # We want a consistent name that works from both ends, so we tell containerd to # alias localhost:${reg_port} to the registry container when pulling images REGISTRY_DIR="/etc/containerd/certs.d/localhost:${reg_port}" for node in $(kind get nodes); do docker exec "${node}" mkdir -p "${REGISTRY_DIR}" cat <<EOF | docker exec -i "${node}" cp /dev/stdin "${REGISTRY_DIR}/hosts.toml" [host."http://${reg_name}:5000"] EOF done # 4. Connect the registry to the cluster network if not already connected # This allows kind to bootstrap the network but ensures they're on the same network if [ "$(docker inspect -f='{{json .NetworkSettings.Networks.kind}}' "${reg_name}")" = 'null' ]; then docker network connect "kind" "${reg_name}" fi # 5. Document the local registry # https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/generic/1755-communicating-a-local-registry cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: local-registry-hosting namespace: kube-public data: localRegistryHosting.v1: | host: "localhost:${reg_port}" help: "https://kind.sigs.k8s.io/docs/user/local-registry/" EOF



এই স্ক্রিপ্টটিপ্রকল্পের রুট ফোল্ডারে পাওয়া যাবে। এবং স্থানীয় ডকার রেজিস্ট্রি ইনস্টল করার জন্য, আমাদের শুধুমাত্র এই ব্যাশ স্ক্রিপ্টটি চালাতে হবে।


IV কিভাবে কোড তৈরি করা হয়েছে

এই ব্লগ পোস্টের জন্য আমি যে কোডটি উদাহরণ দিয়েছি সে সম্পর্কে অনেক কিছু বলার থাকতে পারে। যাইহোক, এই ক্ষেত্রে, আসুন শুধু কয়েকটি মূল দিকগুলিতে ফোকাস করি। আসুনশ্রোতা পরিষেবা থেকে শুরু করি সংগ্রাহক এবং তারপরেডাটাবেসে । যখন আমরা স্থানীয়ভাবে পরিষেবাগুলি চালাই বা এমনকি কন্টেইনারগুলি চালু করার জন্য একটি docker-compose কনফিগারেশন ব্যবহার করি, সাধারণত, আমরা DNS- অ্যাট্রিবিউটেড নামগুলি ব্যবহার করি যা স্বয়ংক্রিয়ভাবে ধারক নাম বা hostname সাথে কনফিগার করা নাম হিসাবে নির্ধারিত হয়৷


k8s এর সাথে, একটি নিয়মের সেট রয়েছে যা হোস্টের নামগুলিকে ক্লাস্টার জুড়ে উপলব্ধ করে। আসুন শ্রোতা এবং সংগ্রাহকের উদাহরণগুলি দেখুন:


শ্রোতার উদাহরণ

লিসেনার হল Spring framework ব্যবহার করে Java তৈরি একটি অ্যাপ্লিকেশন। এইভাবে তৈরি করা সমস্ত অ্যাপ্লিকেশনের মতো, একটি application.properties ফাইলও রয়েছে:

 spring.application.name=wlsm-listener-service server.port=8080 spring.main.web-application-type=reactive spring.webflux.base-path=/app/v1/listener wslm.url.collector=http://localhost:8081/api/v1/collector


এই সমস্ত বৈশিষ্ট্যের মধ্যে, এই মুহূর্তে সবচেয়ে গুরুত্বপূর্ণ যেটির উপর ফোকাস করতে হবে তা হল wslm.url.collector প্রপার্টি। default কনফিগারেশনের সাথে, আমরা কোনো কন্টেইনারাইজড পরিবেশ ব্যবহার করার প্রয়োজন ছাড়াই স্থানীয়ভাবে এই পরিষেবাটি চালাতে পারি। যাইহোক, k8s ক্লাস্টারে, আমাদের collector অ্যাক্সেস করতে সক্ষম হতে হবে এবং এর জন্য, আমাদের কাছে ডেফিনিশন ফাইল application-prod.properties সহ একটি prod প্রোফাইল রয়েছে:

 wslm.url.collector=http://wlsm-collector-deployment.wlsm-namespace.svc.cluster.local:8081/api/v1/collector


এই সম্পত্তি হোস্ট wlsm-collector-deployment.wlsm-namespace.svc.cluster.local পৌঁছানোর চেষ্টা করে। এই ফাইলটি এই কনফিগারেশন অনুসরণ করে:

<Service Name>.<Namespace>.svc.cluster.local

আমরা 5টি বিন্দু-বিচ্ছিন্ন উপাদান পেয়েছি। শেষ তিনটি স্থির, এবং প্রথম দুটি নির্ভর করে আমরা যে মেশিনে পৌঁছানোর চেষ্টা করছি তার উপর। বাম দিকে, আমরা নামস্থানের পরে পরিষেবার নাম রাখি। ক্লাস্টারের মধ্যে পাত্রগুলি একে অপরের সাথে কীভাবে সংযুক্ত থাকে তা বোঝা গুরুত্বপূর্ণ।


কোডের যে অংশটি দেখতে আকর্ষণীয় তা অবশ্যই নিয়ামক এবং পরিষেবা। নিয়ামক এই মত দেখায়:

 @RestController @RequestMapping public class ListenerController { private final ListenerService listenerService; ListenerController(ListenerService listenerService) { this.listenerService = listenerService; } @GetMapping("info") public String info() { return "Listener Service V1"; } @PostMapping("create") public Mono<AnimalLocationDto> sendAnimalLocation( @RequestBody AnimalLocationDto animalLocationDto) { return listenerService.persist(animalLocationDto); } }


এবং পরিষেবাটি এইরকম দেখাচ্ছে:

 @Service public class ListenerService { @Value("${wslm.url.collector:http://localhost:8080}") private String collectorUrl; private final WebClient client = WebClient.create(collectorUrl); HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance(); List<AnimalLocationDto> cache = hazelcastInstance.getList("data"); public Mono<AnimalLocationDto> persist(AnimalLocationDto animalLocationDto) { cache.add(animalLocationDto); return client.post() .uri(collectorUrl.concat("/animals")) .contentType(MediaType.APPLICATION_JSON) .bodyValue(animalLocationDto) .retrieve() .bodyToMono(AnimalLocationDto.class); } }


আপনি ইতিমধ্যে লক্ষ্য করেছেন যে, এই প্রথম অ্যাপ্লিকেশনটি, এই সংগ্রহস্থলে Spring Framework ব্যবহার করে প্রয়োগ করা সমস্ত অ্যাপ্লিকেশনের মতো, প্রতিক্রিয়াশীল এবং তারা সবাই tomcat পরিবর্তে netty ব্যবহার করে। এই মুহূর্তে, আমরা এই কোডে hazelcast ব্যবহার উপেক্ষা করতে পারি। . এটি এই প্রকল্পের পরবর্তী সংস্করণগুলির জন্য ব্যবহার করা হবে৷


কালেক্টর উদাহরণ

সংগ্রাহক এই সময়ে শ্রোতার মতো ঠিক একইভাবে কাজ করে। আপাতত এর একমাত্র দায়িত্ব হল শ্রোতার কাছ থেকে ডেটাবেসে ডেটা রিলে করা এবং এটি করার জন্য, সংগ্রাহককে কেবলমাত্র ডাটাবেসটি ঠিক কোথায় তা জানতে হবে। আসুন application.properties file of this project একই বিশ্লেষণ করি:

 spring.application.name=wlsm-collector-service server.port=8081 spring.main.web-application-type=reactive spring.webflux.base-path=/api/v1/collector spring.r2dbc.url=r2dbc:postgresql://localhost:5432/wlsm spring.r2dbc.username=admin spring.r2dbc.password=admin spring.data.r2dbc.repositories.naming-strategy=org.springframework.data.relational.core.mapping.BasicRelationalPersistentEntityNamingStrategy spring.data.r2dbc.repositories.naming-strategy.table=org.springframework.data.relational.core.mapping.SnakeCaseNamingStrategy spring.data.r2dbc.repositories.naming-strategy.column=org.springframework.data.relational.core.mapping.SnakeCaseNamingStrategy


এই বৈশিষ্ট্যগুলি পরিষেবা চালু করার জন্য সর্বনিম্ন প্রয়োজন৷ যাইহোক, এটি শুধুমাত্র স্থানীয়ভাবে এটি চালানোর জন্য সক্ষম। এবং এই পরিষেবার জন্য, আমাদের কাছে prod প্রোফাইল ফাইলও রয়েছে এবং আমরা এখানে application-prod.properties এ এটি দেখতে পারি:

 spring.r2dbc.url=r2dbc:postgresql://wlsm-database-deployment.wlsm-namespace.svc.cluster.local:5432/wlsm


ডাটাবেস সংযোগটি এই ক্ষেত্রে ডাটাবেসের হোস্টকে উল্লেখ করে:

wlsm-database-deployment.wlsm-namespace.svc.cluster.local


যা আবার একই বিশ্লেষণ অনুসরণ করে যা আমরা আগে দেখেছি। বাম দিকে, আমরা পরিষেবার নাম দেখতে পাচ্ছি, তারপরে নামস্থানটি svc.cluster.local এর সাথে যুক্ত করা হয়েছে।


এবং এই পরিষেবার জন্য, আমরা একটি নিয়ামক এবং একটি পরিষেবাও ব্যবহার করি। নিয়ামক এই মত দেখায়:

 @RestController @RequestMapping class CollectorController( val collectorService: CollectorService ) { @PostMapping("animals") suspend fun listenAnimalLocation(@RequestBody animalLocationDto: AnimalLocationDto): AnimalLocationDto = run { collectorService.persist(animalLocationDto) animalLocationDto } }


এবং পরিষেবাটি এইরকম দেখাচ্ছে:

 @Service class CollectorService( val applicationEventPublisher: ApplicationEventPublisher ) { fun persist(animalLocationDto: AnimalLocationDto) = applicationEventPublisher.publishEvent(AnimalLocationEvent(animalLocationDto)) }


পরিষেবাটি একটি ইভেন্ট প্রকাশক ব্যবহার করে যাকে বলা হয় applicationEventPublisher , যা একটি ইভেন্ট স্ট্রিমিং আর্কিটেকচার অনুসরণ করে যা পরবর্তীতে এই ইভেন্ট লিসেনারে পরিচালনা করা হয়, যা আমরা সহজেই দেখতে পারি যে এটি প্রতিক্রিয়াশীল আর্কিটেকচার বাস্তবায়নের দৃষ্টান্তে রাখতে r2dbc ব্যবহার করে:

 @Service class EventHandlerService( val animalLocationDao: AnimalLocationDao ) { @EventListener fun processEvent(animalLocationEvent: AnimalLocationEvent){ println(animalLocationEvent) runBlocking(Dispatchers.IO) { animalLocationDao.save(animalLocationEvent.animalLocationDto.toEntity()) } } }



V. স্ক্রিপ্ট স্থাপন করা

স্থাপন করা সাধারণত k8s সাথে করা একটি খুব সহজ কাজ। যাইহোক, আমাদের পরিষেবাগুলির জন্য প্রয়োজনীয় কনফিগারেশনের দিকে নজর দেওয়াও গুরুত্বপূর্ণ৷ উদাহরণস্বরূপ, আসুন শ্রোতা বাস্তবায়নের দিকে নজর দেওয়া যাক:

 apiVersion: v1 kind: Namespace metadata: name: wlsm-namespace labels: kuma.io/sidecar-injection: enabled --- apiVersion: apps/v1 kind: Deployment metadata: name: wlsm-listener namespace: wlsm-namespace spec: replicas: 1 selector: matchLabels: app: wlsm-listener template: metadata: labels: app: wlsm-listener spec: containers: - name: wlsm-listener-service image: localhost:5001/wlsm-listener-service:latest imagePullPolicy: Always ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: wlsm-listener-deployment namespace: wlsm-namespace spec: selector: app: wlsm-listener ports: - protocol: TCP appProtocol: http port: 8080


এই কনফিগারেশনে তিনটি ব্লক রয়েছে। প্রথম ব্লকটি নামস্থান ব্লক। নামস্থান কনফিগারেশন অত্যন্ত গুরুত্বপূর্ণ যাতে কুমা দূত সাইডকারগুলিকে ইনজেকশন দিতে সক্ষম হয় যা এটির নীতিগুলি প্রয়োগ করতে হবে৷ একটি সংজ্ঞায়িত নামস্থান ছাড়া, kuma এটি করতে সক্ষম হবে না। কুমা কনফিগার করার সময় আমাদের অন্য যে বিষয়ে মনোযোগ দিতে হবে তা হল নামস্থানে অবশ্যই সঠিক লেবেল থাকতে হবে যা কুমা চিনবে:

kuma.io/sidecar-injection: enabled.


কুমাকে কাজ করার জন্য সঠিক লেবেল সহ নামস্থানের সংজ্ঞা অত্যাবশ্যক৷ দ্বিতীয় ব্লকে, আমরা স্থাপনার সংজ্ঞা খুঁজে পাই। এইভাবে আমরা সংজ্ঞায়িত করি যে আমাদের কুবারনেটস ক্লাস্টারে আমাদের পডের স্থাপনা কেমন হবে। এখানে ফোকাস করার জন্য যেটা গুরুত্বপূর্ণ তা হল image , imagePullPolicy এবং containerPort । ছবিটি আমরা যে ডকার ইমেজটি ব্যবহার করছি তার সম্পূর্ণ ট্যাগ।


আমাদের ডকার রেজিস্ট্রির জন্য যে পোর্টটি কনফিগার করা হয়েছে kind হল 5001, এবং এটি আমাদের ছবির ট্যাগে অন্তর্ভুক্ত করা হয়েছে। এটি একটি ট্যাগ হিসাবে কাজ করে কিন্তু আমাদের ডকার রেজিস্ট্রির সাথে সংযোগ হিসাবেও কাজ করে। এইভাবে, আমরা চিত্রগুলি টানতে পারি এবং আমাদের কুবারনেটস পরিবেশে চালানোর জন্য আমাদের ধারক তৈরি করতে পারি।


কিন্তু, অবশ্যই, ইমেজ ব্যবহার করতে সক্ষম হতে, আমাদের সেগুলি তৈরি করতে হবে, এবং এর জন্য, listener উদাহরণ এবং database উদাহরণে এটি কীভাবে করা হয় তা একবার দেখে নেওয়া যাক। listener জন্য ডকার ইমেজ এই মত সংজ্ঞায়িত করা হয়:

 FROM eclipse-temurin:21-jdk-alpine WORKDIR /root ENV LANG=C.UTF-8 COPY entrypoint.sh /root COPY build/libs/wlsm-listener-service.jar /root/wlsm-listener-service.jar ENTRYPOINT ["/root/entrypoint.sh"]


এই সব শুরু হয় eclipse-temurin:21-jdk-alpine নামে একটি বেস ইমেজ থেকে। এর পরে, আমরা কেবল প্রকল্প তৈরি করে তৈরি করা জারটি অনুলিপি করি এবং তারপরে এটির একটি অনুলিপি আমাদের ছবিতে তৈরি করি। তার আগে, আমরা কন্টেইনারে entrypoint.sh কপি করি এবং এটি ব্যবহার করার জন্য ENTRYPOINT সংজ্ঞায়িত করি। entrypoint কেবল জারটিকে এভাবে কল করে:

 #!/usr/bin/env sh java -jar -Dspring.profiles.active=prod wlsm-listener-service.jar


database পরিষেবাটি বেশ ভিন্ন কারণ এটি কয়েকটি স্ক্রিপ্ট ব্যবহার করে যা ওপেনসোর্স এবং অনলাইনে উপলব্ধ:

 FROM postgres:15 COPY . /docker-entrypoint-initdb.d COPY ./multiple /docker-entrypoint-initdb.d/multiple ENV POSTGRES_USER=admin ENV POSTGRES_PASSWORD=admin ENV POSTGRES_MULTIPLE_DATABASES=wlsm EXPOSE 5432


এই স্ক্রিপ্টটি ডকার init ডিরেক্টরিতে নিম্নলিখিত ফাইল এবং ফোল্ডারের একটি অনুলিপি তৈরি করে: create-multiple-postgresql-databases.sh এবং multiple । অবশেষে, আমরা আমাদের ডাটাবেস এবং ব্যবহারকারীর নাম/পাসওয়ার্ড সংমিশ্রণগুলিকে সংজ্ঞায়িত করতে সেই স্ক্রিপ্টগুলিতে ব্যবহৃত ভেরিয়েবলগুলিকে সংজ্ঞায়িত করি।


নিম্নলিখিত স্কিমা ব্যবহার করে ডাটাবেস তৈরি করা হয়:

 CREATE TABLE families( id uuid DEFAULT gen_random_uuid(), name VARCHAR(100), PRIMARY KEY(id) ); CREATE TABLE genuses( id uuid DEFAULT gen_random_uuid(), name VARCHAR(100), PRIMARY KEY(id) ); CREATE TABLE species( id uuid DEFAULT gen_random_uuid(), common_name VARCHAR(100), family uuid, genus uuid, PRIMARY KEY(id), CONSTRAINT fk_species FOREIGN KEY(family) REFERENCES families(id), CONSTRAINT fk_genus FOREIGN KEY(genus) REFERENCES genuses(id) ); CREATE TABLE animal ( id uuid DEFAULT gen_random_uuid(), name VARCHAR(100), species_id uuid, PRIMARY KEY(id), CONSTRAINT fk_species FOREIGN KEY(species_id) REFERENCES species(id) ); CREATE TABLE animal_location ( id uuid DEFAULT gen_random_uuid(), animal_id uuid, latitude BIGINT, longitude BIGINT, PRIMARY KEY(id), CONSTRAINT fk_animal FOREIGN KEY(animal_id) REFERENCES animal(id) );


এবং, একটি ডেটা উদাহরণ হিসাবে, আমরা piquinho নামে একটি প্রাণী নিবন্ধন করব। পিকুইনহো হল একটি ভ্রমণকারী অ্যালবাট্রসের নাম যা সারা বিশ্বে ভ্রমণ করছে, যার সাথে একটি সেন্সর সংযুক্ত রয়েছে এবং সেন্সর আমাদের কাছে যে ডেটা পাঠাচ্ছে আমরা তা পড়ছি। দুটি টেবিল আছে যা প্রজাতিকে সংজ্ঞায়িত করে। এটি হল প্রজাতি এবং প্রজাতি যা প্রজাতিকে সংজ্ঞায়িত করে। এগুলি হল টেবিল families এবং genuses


সারণী species প্রাণীটি যে প্রজাতির অন্তর্গত তা সংজ্ঞায়িত করে। অবশেষে, আমরা একই নামের টেবিলে একটি animal সংজ্ঞায়িত করি যেখানে প্রজাতি এবং প্রাণীর নাম নিবন্ধিত হয়। ডাটাবেস এই মত দেখায়:
ছবির বর্ণনা

তৈরি করতে, ছবি তৈরি করতে এবং আমাদের প্রকল্প শুরু করতে, আমরা নিম্নলিখিত কমান্ডগুলি চালাতে পারি যা Makefile উপলব্ধ:

 make make create-and-push-images make k8s-apply-deployment


প্রথম তৈরি শুধুমাত্র একটি gradle build কমান্ড. দ্বিতীয় কমান্ড ভেরিয়েবল ব্যবহার করেছে:

 MODULE_TAGS := aggregator \ collector \ listener \ management \ database


চালানোর জন্য:

 docker images "*/*wlsm*" --format '{{.Repository}}' | xargs -I {} docker rmi {} @for tag in $(MODULE_TAGS); do \ export CURRENT=$(shell pwd); \ echo "Building Image $$image..."; \ cd "wlsm-"$$tag"-service"; \ docker build . --tag localhost:5001/"wlsm-"$$tag"-service"; \ docker push localhost:5001/"wlsm-"$$tag"-service"; \ cd $$CURRENT; \ done


এটি কেবল প্রতিটি মডিউলের মধ্য দিয়ে যায় এবং একটি সাধারণ জেনেরিক কমান্ড ব্যবহার করে যা MODULE_TAGS এ প্রদত্ত মান প্রতি পরিবর্তন করে ছবিগুলি তৈরি করে এবং পোর্ট 5001-এর স্থানীয় রেজিস্ট্রিতে ঠেলে দেয়৷ একই কৌশল অনুসরণ করে, আমরা তারপরে আমাদের স্থাপন করতে তৃতীয় কমান্ডটি ব্যবহার করতে পারি শুঁটি এই তৃতীয় কমান্ডটি একটি ভিন্ন লুপ ব্যবহার করে যা এইরকম দেখায়:

 @for tag in $(MODULE_TAGS); do \ export CURRENT=$(shell pwd); \ echo "Applying File $$tag..."; \ cd "wlsm-"$$tag"-service"; \ kubectl apply -f $$tag-deployment.yaml --force; \ cd $$CURRENT; \ done


এই ক্ষেত্রে, এটি প্রতিটি স্থাপনার স্ক্রিপ্ট প্রতিটি একক পরিষেবাতে প্রয়োগ করে। যদি আমরা kubectl get pods --all-namespaces কমান্ডটি চালাই, তাহলে আমাদের এই আউটপুটটি পাওয়া উচিত:

 NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-76f75df574-dmt5m 1/1 Running 0 5m21s kube-system coredns-76f75df574-jtrfr 1/1 Running 0 5m21s kube-system etcd-kind-control-plane 1/1 Running 0 5m38s kube-system kindnet-7frts 1/1 Running 0 5m21s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 5m36s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 5m36s kube-system kube-proxy-njzvl 1/1 Running 0 5m21s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 5m36s kuma-system kuma-control-plane-5f47fdb4c6-7sqmp 1/1 Running 0 17s local-path-storage local-path-provisioner-7577fdbbfb-5qnxr 1/1 Running 0 5m21s wlsm-namespace wlsm-aggregator-64fc4599b-hg9qw 1/1 Running 0 4m23s wlsm-namespace wlsm-collector-5d44b54dbc-swf84 1/1 Running 0 4m23s wlsm-namespace wlsm-database-666d794c87-pslzp 1/1 Running 0 4m22s wlsm-namespace wlsm-listener-7bfbcf799-f44f5 1/1 Running 0 4m23s wlsm-namespace wlsm-management-748cf7b48f-8cjh9 1/1 Running 0 4m23s


এই মুহুর্তে আমাদের এখানে যা পর্যবেক্ষণ করা উচিত তা হল kuma-control-plane , kube-controller-manager এবং আমাদের নিজস্ব কাস্টম wlsm-namespace এ চলমান সমস্ত পরিষেবার উপস্থিতি৷ আমাদের ক্লাস্টার বাইরে থেকে বিচ্ছিন্ন, এবং বিভিন্ন পোর্ট অ্যাক্সেস করতে সক্ষম হওয়ার জন্য, আমাদের প্রতিটি পডের জন্য port-forwarding তৈরি করতে হবে যা আমরা অ্যাক্সেস করতে চাই। এর জন্য, আমরা এই কমান্ডগুলি পৃথক ট্যাবে জারি করতে পারি:

আমরা k9s দেখেও এটি দেখতে পারি:

ছবির বর্ণনা

 kubectl port-forward svc/wlsm-collector-deployment -n wlsm-namespace 8081:8081 kubectl port-forward svc/wlsm-listener-deployment -n wlsm-namespace 8080:8080 kubectl port-forward svc/wlsm-database-deployment -n wlsm-namespace 5432:5432 kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681


VI. অ্যাপ্লিকেশন চলমান

অ্যাপ্লিকেশনটি চালানোর জন্য, আমাদের সমস্ত পোর্ট খুলতে হবে এবং যখন সেগুলি খোলা থাকে, তখন আমাদের স্ক্রিনে এরকম কিছু দেখতে হবে:

ছবির বর্ণনা

আমরা localhost এবং পোর্ট 5432 ব্যবহার করে ডাটাবেসের সাথে সংযোগ করতে পারি। সংযোগ স্ট্রিং হল এই: jdbc:postgresql://localhost:5432/wlsm । এবং এটি অ্যাক্সেস করতে আমরা তারপর admin / admin ব্যবহারকারীর নাম/পাসওয়ার্ড সংমিশ্রণ ব্যবহার করি।


কোনো পরীক্ষা করার আগে আমাদের যা করতে হবে তা হল Piquinho এর আইডি জানা, এবং আমরা ইন্টেলিজ ডাটাবেস টুল ব্যবহার করে এটি করতে পারি:

ছবির বর্ণনা

প্রকল্পের রুট ফোল্ডারে test-requests.http নামে একটি ফাইল রয়েছে। আমাদের খোলা পোর্টগুলির বিরুদ্ধে REST অনুরোধ তৈরি করার জন্য এটি একটি স্ক্র্যাচ ফাইল:

 ### GET http://localhost:8080/app/v1/listener/info ### POST http://localhost:8080/app/v1/listener/create Content-Type: application/json { "animalId": "2ffc17b7-1956-4105-845f-b10a766789da", "latitude": 52505252, "longitude": 2869152 } ### POST http://localhost:8081/api/v1/collector/animals Content-Type: application/json { "animalId": "2ffc17b7-1956-4105-845f-b10a766789da", "latitude": 52505252, "longitude": 2869152 }


এই ফাইলটি ব্যবহার করতে সক্ষম হওয়ার জন্য, আমাদের শুধুমাত্র ID প্রতিস্থাপন করতে হবে, এই উদাহরণে, 2ffc17b7-1956-4105-845f-b10a766789da থেকে d5ad0824-71c0-4786-a04a-ac2b9a032da4 । এই ক্ষেত্রে, আমরা সংগ্রাহক বা শ্রোতার কাছ থেকে অনুরোধ করতে পারি। উভয় অনুরোধ কাজ করা উচিত, এবং আমরা অনুরোধ প্রতি এই ধরনের প্রতিক্রিয়া পরে দেখতে হবে:

 { "animalId": "d5ad0824-71c0-4786-a04a-ac2b9a032da4", "latitude": 52505252, "longitude": 2869152 } Response file saved. > 2024-04-12T001024.200.json Response code: 200 (OK); Time: 7460ms (7 s 460 ms); Content length: 91 bytes (91 B)


যেহেতু উভয় পোর্ট খোলা হয়েছে এবং তারা, এই সময়ে, একই পেলোড টাইপ ভাগ করে, আমরা শ্রোতা এবং সংগ্রাহকের কাছে একই অনুরোধ করতে পারি। এই দুটি অনুরোধ করার পরে, আমাদের টেবিলের animal_locations ফলাফল খুঁজে পাওয়া উচিত:

ছবির বর্ণনা

সুতরাং, এটি শুধুমাত্র নিশ্চিত করে যে ক্লাস্টারটি সঠিকভাবে চলছে, এবং এখন, আমরা আমাদের কুমা জাল দিয়ে নীতি পরীক্ষা করতে প্রস্তুত।

VII. MeshTrafficPermission - পার্ট I

MeshTrafficPermission হল একটি বৈশিষ্ট্য যা আমরা কুমাতে বেছে নিতে পারি এবং এটি সম্ভবত সবচেয়ে বেশি ব্যবহৃত একটি।


কিন্তু প্রথমে, কুমা কন্ট্রোল প্লেনটি অন্বেষণ করার জন্য একটু সময় নেওয়া যাক। সমস্ত ফরওয়ার্ডিং চালু রেখে, আমরা শুধু localhost:5681/gui- এ যেতে পারি এবং আমাদের কুমা মেশগুলিকে কল্পনা করতে পারি। মূল পৃষ্ঠায়, আমাদের এরকম কিছু দেখতে হবে:

ছবির বর্ণনা

এই মুহুর্তে দেখার মতো তেমন কিছুই নেই, তবে এখন MeshTrafficPermission প্রয়োগ করা যাক:

 echo "apiVersion: kuma.io/v1alpha1 kind: MeshTrafficPermission metadata: namespace: kuma-system name: mtp spec: targetRef: kind: Mesh from: - targetRef: kind: Mesh default: action: Allow" | kubectl apply -f -


একবার আমরা এটি প্রয়োগ করলে, আমাদের এইরকম একটি প্রতিক্রিয়া পাওয়া উচিত: meshtrafficpermission.kuma.io/mtp created

অষ্টম। জাল

আমাদের ক্লাস্টারের সেটআপের ক্ষেত্রে জাল প্রয়োগ করা খুব বেশি পরিবর্তিত হয় না। এটি যা করে তা হল আমাদের ট্রাফিক রাউটিং নীতি সেট আপ করার অনুমতি দেয়৷


এমন অনেক জিনিস আছে যা থেকে আমরা বেছে নিতে পারি, কিন্তু সবচেয়ে সুস্পষ্ট জিনিসগুলির মধ্যে একটি হল mTLS. অন্যথায় পারস্পরিক TLS হিসাবে উল্লেখ করা হয়, যার অর্থ খুব সংক্ষিপ্তভাবে, সার্টিফিকেটগুলি পারস্পরিকভাবে গৃহীত এবং যাচাই করা হয় যাতে পক্ষগুলির মধ্যে পরিচয় প্রতিষ্ঠা করা যায় এবং এনক্রিপ্ট করা ডেটা ট্র্যাফিক স্থাপন করা হয়।


এই সহজ Mesh কনফিগারেশন ব্যবহার করে এটি স্বয়ংক্রিয়ভাবে আমাদের জন্য করা যেতে পারে:

 echo "apiVersion: kuma.io/v1alpha1 kind: Mesh metadata: name: default spec: mtls: enabledBackend: ca-1 backends: - name: ca-1 type: builtin" | kubectl apply -f -


এই নীতি প্রয়োগ করার পরে আমরা এইরকম একটি সতর্কতা দেখতে পেতে পারি:

Warning: resource meshes/default is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.

আপাতত, আমরা এই সতর্কতা উপেক্ষা করতে পারি।

IX MeshTrafficPermission - পার্ট II

এখন, মজার অংশটি আসে, এবং প্রথমে আমরা যা করতে যাচ্ছি তা হল সমস্ত পডের মধ্যে সমস্ত ট্র্যাফিক অক্ষম করা:

 echo " apiVersion: kuma.io/v1alpha1 kind: MeshTrafficPermission metadata: namespace: wlsm-namespace name: mtp spec: targetRef: kind: Mesh from: - targetRef: kind: Mesh default: action: Deny" | kubectl apply -f -


এবং আমরা নিশ্চিতকরণ বার্তা পাওয়ার পরে meshtrafficpermission.kuma.io/mtp configured , যদি আমরা পোর্ট-ফরওয়ার্ডিং ব্যবহার করে কোনো অনুরোধ করার চেষ্টা করি, আমরা পাব:

 HTTP/1.1 500 Internal Server Error Content-Type: application/json Content-Length: 133 { "timestamp": "2024-04-12T07:09:26.718+00:00", "path": "/create", "status": 500, "error": "Internal Server Error", "requestId": "720749ce-56" } Response file saved. > 2024-04-12T090926.500.json Response code: 500 (Internal Server Error); Time: 10ms (10 ms); Content length: 133 bytes (133 B)


এর মানে হল যে পডের মধ্যে সমস্ত ট্র্যাফিক অস্বীকার করা হচ্ছে। আমাদের এখন যা আছে তা হল আমাদের প্রতিষ্ঠানের মধ্যে সম্ভাব্য খারাপ অভিনেতাদের বিরুদ্ধে সুরক্ষিত একটি অভ্যন্তরীণ ব্যবস্থা, কিন্তু আমরা এখন সমস্ত পডের মধ্যে ট্র্যাফিক ব্লক করেছি। সুতরাং, mTLS একটি দুর্দান্ত জিনিস, তবে সমস্ত ট্র্যাফিক ব্লক করা মোটেই নয়।


এটিকে নিখুঁত করার উপায় হল শুধুমাত্র সেই DENY সমস্ত নিয়মের ব্যতিক্রম করা, এবং এটি করার জন্য, আমাদের একটি নীতি দরকার যা শ্রোতা এবং সংগ্রাহক এবং সংগ্রাহক এবং ডাটাবেসের মধ্যে ট্র্যাফিকের অনুমতি দেবে। সংগ্রাহক এবং ডাটাবেসের মধ্যে ট্রাফিক দিয়ে শুরু করা যাক:

 echo " apiVersion: kuma.io/v1alpha1 kind: MeshTrafficPermission metadata: namespace: kuma-system name: wlsm-database spec: targetRef: kind: MeshService name: wlsm-database-deployment_wlsm-namespace_svc_5432 from: - targetRef: kind: MeshService name: wlsm-collector-deployment_wlsm-namespace_svc_8081 default: action: Allow" | kubectl apply -f -


এই ক্ষেত্রে, আমরা যা করছি তা হল targetRef সংগ্রাহক থেকে targetRef ডাটাবেসে ডেটা ট্র্যাফিক প্রবাহিত হতে দেওয়া। আপনি যদি এটি না জানেন, তাহলে সম্ভবত এটি লক্ষ করা গুরুত্বপূর্ণ যে কুমা name কীভাবে ব্যাখ্যা করে, যা hostname তৈরির মতোই কার্যকরী উদ্দেশ্যেও ব্যবহৃত হয়।


এই name তৈরি করার জেনেরিক উপায় হল এইরকম:

<service name>_<namespace>_svc_<service port>


এই ক্ষেত্রে, বিভাজক একটি আন্ডারস্কোর, এবং এইভাবে একটি নাম তৈরি করলে Kuma ঠিক কী অনুমতি দেওয়া হয়েছে তা জানতে দেয়। এই ক্ষেত্রে, যদি আমরা এই নীতিটি প্রয়োগ করি, তাহলে আমরা এই প্রতিক্রিয়া পাওয়ার পরে সংগ্রাহকের কাছে অনুরোধ পাঠাতে সক্ষম হব: meshtrafficpermission.kuma.io/wlsm-database created .


এবং সেগুলি তৈরি করার সময়, প্রতিক্রিয়াটি এখন 200 হওয়া উচিত তা নিশ্চিত করে যে অবস্থান রেকর্ডটি সংগ্রাহকের কাছে পাঠানো হয়েছে:

 POST http://localhost:8081/api/v1/collector/animals HTTP/1.1 200 OK Content-Type: application/json Content-Length: 91 { "animalId": "a3a1bc1c-f284-4876-a84f-f75184b6998f", "latitude": 52505252, "longitude": 2869152 } Response file saved. > 2024-04-12T091754.200.json Response code: 200 (OK); Time: 1732ms (1 s 732 ms); Content length: 91 bytes (91 B)


যাইহোক, আমরা এখনও শ্রোতা এবং সংগ্রাহকের মধ্যে ট্র্যাফিকের ব্যতিক্রমগুলি সংজ্ঞায়িত করিনি, তাই এইভাবে অনুরোধ করার ফলে এটি হবে:

 HTTP/1.1 500 Internal Server Error Content-Type: application/json Content-Length: 133 { "timestamp": "2024-04-12T07:18:54.149+00:00", "path": "/create", "status": 500, "error": "Internal Server Error", "requestId": "e8973d33-62" } Response file saved. > 2024-04-12T091854-1.500.json Response code: 500 (Internal Server Error); Time: 10ms (10 ms); Content length: 133 bytes (133 B)


এবং এই অবশ্যই প্রত্যাশিত. এখন এই ডেটা ট্র্যাফিকের জন্য অন্য নীতি প্রয়োগ করা যাক:

 echo " apiVersion: kuma.io/v1alpha1 kind: MeshTrafficPermission metadata: namespace: kuma-system name: wlsm-collector spec: targetRef: kind: MeshService name: wlsm-collector-deployment_wlsm-namespace_svc_8081 from: - targetRef: kind: MeshService name: wlsm-listener-deployment_wlsm-namespace_svc_8080 default: action: Allow" | kubectl apply -f -


এখন শ্রোতার কাছ থেকে সংগ্রাহকের কাছে অনুরোধগুলি সম্পাদন করা সম্ভব হচ্ছে:

 POST http://localhost:8080/app/v1/listener/create HTTP/1.1 200 OK Content-Type: application/json Content-Length: 91 { "animalId": "a3a1bc1c-f284-4876-a84f-f75184b6998f", "latitude": 52505252, "longitude": 2869152 } Response file saved. > 2024-04-12T092039-2.200.json Response code: 200 (OK); Time: 14ms (14 ms); Content length: 91 bytes (91 B)

এক্স - মেশফল্ট ইনজেকশন

পরিশেষে এবং শুধুমাত্র একটি উদাহরণ হিসাবে আরেকটি বৈশিষ্ট্য প্রদান করার জন্য, আমরা MeshFaultInjection নামক আরেকটি বৈশিষ্ট্যও ব্যবহার করতে পারি, যা Kuma সাথে পরীক্ষা করার সময় খুবই কার্যকর হতে পারে। আমরা আমাদের জালের মধ্যে সম্ভাব্য সমস্যাগুলি অনুকরণ করতে পারি এবং উদাহরণস্বরূপ ত্রুটি হ্যান্ডলিং সঠিকভাবে করা হচ্ছে কিনা তা পরীক্ষা করতে পারি।


আমরা অন্যান্য জিনিসগুলিও পরীক্ষা করতে পারি যেমন আমাদের কনফিগার করা সার্কিট ব্রেকারগুলি কীভাবে ত্রুটিপূর্ণ সংযোগ বা উচ্চ-দরের অনুরোধে প্রতিক্রিয়া দেখাতে পারে।


সুতরাং, এর চেষ্টা করা যাক. MeshFaultInjection প্রয়োগ করার একটি উপায় হল এইরকম:

 echo " apiVersion: kuma.io/v1alpha1 kind: MeshFaultInjection metadata: name: default namespace: kuma-system labels: kuma.io/mesh: default spec: targetRef: kind: MeshService name: wlsm-collector-deployment_wlsm-namespace_svc_8081 from: - targetRef: kind: MeshService name: wlsm-listener-deployment_wlsm-namespace_svc_8080 default: http: - abort: httpStatus: 500 percentage: 50" | kubectl apply -f -


এই নীতির সাথে, আমরা বলছি যে শ্রোতা থেকে আউটবাউন্ড এবং সংগ্রাহকের কাছে ট্রাফিকের সাফল্যের 50% সম্ভাবনা থাকবে। অনুরোধের ফলাফলগুলি অপ্রত্যাশিত, তাই এই নীতি প্রয়োগ করার পরে, আমরা শ্রোতার শেষ পয়েন্টে ত্রুটি বা সফল অনুরোধ আশা করতে পারি।

 POST http://localhost:8080/app/v1/listener/create HTTP/1.1 500 Internal Server Error Content-Type: application/json Content-Length: 133 { "timestamp": "2024-04-12T07:28:00.008+00:00", "path": "/create", "status": 500, "error": "Internal Server Error", "requestId": "2206f29e-78" } Response file saved. > 2024-04-12T092800.500.json Response code: 500 (Internal Server Error); Time: 8ms (8 ms); Content length: 133 bytes (133 B)


 POST http://localhost:8080/app/v1/listener/create HTTP/1.1 200 OK Content-Type: application/json Content-Length: 91 { "animalId": "a3a1bc1c-f284-4876-a84f-f75184b6998f", "latitude": 52505252, "longitude": 2869152 } Response file saved. > 2024-04-12T092819.200.json Response code: 200 (OK); Time: 13ms (13 ms); Content length: 91 bytes (91 B)


পরিশেষে, শুধুমাত্র আগ্রহের বাইরে, আমরা দেখতে পারি আমাদের animal_location টেবিলটি এখন কেমন দেখাচ্ছে:

ছবির বর্ণনা

একাদশ - উপসংহার

আমি আশা করি আপনি এখন পর্যন্ত এই নিবন্ধটি অনুসরণ করতে সক্ষম হয়েছেন এবং আপনি আপনার মেশিনে একটি ক্লাস্টার চালাতে সক্ষম হয়েছেন। যাইহোক এই নিবন্ধটি পড়ার জন্য এবং কুমা সম্পর্কে আরও কিছু বুঝতে এবং শিখতে আপনার কিছুটা সময় দেওয়ার জন্য ধন্যবাদ। আমি ব্যক্তিগতভাবে এটির জন্য একটি দুর্দান্ত ব্যবহার এবং Kuma জন্য একটি দুর্দান্ত ভবিষ্যত দেখতে পাচ্ছি কারণ এটি কনফিগার করা এবং আমাদের নেটওয়ার্ক এবং আমাদের পরিবেশের অনেক বেশি দানাদার নিয়ন্ত্রণ করা সম্ভব করে তোলে।


এর এন্টারপ্রাইজ সংস্করণ, Kong-Mesh , বেশ সম্পূর্ণ বলে মনে হচ্ছে। কুমা ওপেন সোর্স। এবং এটি পরীক্ষার জন্য এবং এন্টারপ্রাইজের জন্যও দুর্দান্ত। আমি মেশের বিষয়বস্তুকে খুব আকর্ষণীয় বলে মনে করি, এবং আমি মনে করি Kuma কীভাবে মেশগুলি কাজ করে তা শিখতে এবং কীভাবে আমরা আমাদের নেটওয়ার্কের মধ্যে ডেটা প্রবাহকে আরও ভালভাবে নিয়ন্ত্রণ করতে পারি সে সম্পর্কে একটি অনুভূতি পেতে একটি দুর্দান্ত উপায় সরবরাহ করে।


আমরা যদি আমাদের পরিষেবাগুলির অবস্থা দেখতে চাই, তাহলে আমরা এই localhost অবস্থানে আমাদের Kuma কন্ট্রোল প্লেনে যেতে পারি: http://localhost:5681/gui/meshes/default/services?page=1&size=50 :

ছবির বর্ণনা

কুমা কন্ট্রোল প্লেনে, আমরা ইনস্টল করা নীতিগুলিও দেখতে পারি, আমাদের পডের স্থিতি পরীক্ষা করতে পারি, পটভূমিতে কী ঘটছে তা নিরীক্ষণ করতে পারি এবং সাধারণত, আমাদের জালে কী ঘটছে এবং কীভাবে এটি ঘটছে তার একটি সংক্ষিপ্ত বিবরণ পেতে পারি। কনফিগার করা হয়। আমি আপনাকে আমন্ত্রণ জানাচ্ছি কেবলমাত্র অ্যাপ্লিকেশনটির মাধ্যমে যেতে এবং আপনি আমাদের ইনস্টল করা নীতিগুলির স্থিতি পরীক্ষা করতে পারেন কিনা তা দেখতে। কুমা কন্ট্রোল প্লেন, ওরফে, জিইউআই, আমাদের মেশকে বোঝা এবং অনুসরণ করা সহজ হওয়ার জন্য সঠিকভাবে তৈরি করা হয়েছে।

XII - সম্পদ

আমি এখানে আমার JESPROTECH YouTube চ্যানেলে এটি সম্পর্কে একটি ভিডিও তৈরি করেছি: