অ্যান্থোস সার্ভিস মেশ ওয়ার্কশপ: ল্যাব গাইড

1. আলফা ওয়ার্কশপ

গুরুত্বপূর্ণ দ্রষ্টব্য: এটি একটি আলফা ওয়ার্কশপ এবং এটি কঠোরভাবে একটি প্রশিক্ষকের নেতৃত্বে শ্রেণীকক্ষ প্রশিক্ষণের উদ্দেশ্যে।

কর্মশালার লিঙ্ক কোডল্যাব bit.ly/asm-workshop

2. ওভারভিউ

স্থাপত্য চিত্র

এই ওয়ার্কশপটি একটি হ্যান্ডস-অন ইমারসিভ অভিজ্ঞতা যা উৎপাদনে GCP-এ বিশ্বব্যাপী বিতরণ করা পরিষেবাগুলি কীভাবে সেট আপ করতে হয় তার মধ্য দিয়ে যায়। ব্যবহৃত প্রধান প্রযুক্তিগুলি হল কম্পিউটের জন্য Google Kubernetes Engine (GKE) এবং নিরাপদ সংযোগ, পর্যবেক্ষণযোগ্যতা এবং উন্নত ট্র্যাফিক গঠন তৈরি করতে Istio পরিষেবা জাল । এই কর্মশালায় ব্যবহৃত সমস্ত অনুশীলন এবং সরঞ্জামগুলি যা আপনি উত্পাদনে ব্যবহার করবেন।

এজেন্ডা

• মডিউল 0 - ভূমিকা এবং প্ল্যাটফর্ম সেটআপ
• ভূমিকা এবং স্থাপত্য
• সার্ভিস মেশ এবং ইস্টিও/এএসএম-এর ভূমিকা
• ল্যাব: অবকাঠামো সেটআপ: ব্যবহারকারীর কর্মপ্রবাহ
• বিরতি
• QnA
• মডিউল 1 - ASM এর সাথে অ্যাপ্লিকেশন ইনস্টল, সুরক্ষিত এবং নিরীক্ষণ করুন
• রেপো মডেল: অবকাঠামো এবং কুবারনেটস রেপো ব্যাখ্যা করা হয়েছে
• ল্যাব: নমুনা অ্যাপ্লিকেশন স্থাপন
• বিতরণ করা পরিষেবা এবং পর্যবেক্ষণযোগ্যতা
• দুপুরের খাবার
• ল্যাব: স্ট্যাকড্রাইভারের সাথে পর্যবেক্ষণযোগ্যতা
• QNA
• মডিউল 2 - DevOps - ক্যানারি রোলআউট, নীতি/RBAC
• মাল্টি ক্লাস্টার পরিষেবা আবিষ্কার এবং নিরাপত্তা/নীতি
• ল্যাব: মিউচুয়াল টিএলএস
• ক্যানারি স্থাপনা
• ল্যাব: ক্যানারি স্থাপনা
• নিরাপদ মাল্টি ক্লাস্টার গ্লোবাল লোড ব্যালেন্সিং
• বিরতি
• ল্যাব: অনুমোদন নীতি
• QNA
• মডিউল 3 - ইনফ্রা অপারেশন - প্ল্যাটফর্ম আপগ্রেড
• বিতরণ সেবা বিল্ডিং ব্লক
• ল্যাব: অবকাঠামো স্কেলিং
• পরবর্তী পদক্ষেপ

স্লাইড

এই কর্মশালার স্লাইডগুলি নিম্নলিখিত লিঙ্কে পাওয়া যাবে:

এএসএম ওয়ার্কশপ স্লাইড

পূর্বশর্ত

এই কর্মশালার সাথে এগিয়ে যাওয়ার আগে নিম্নলিখিতগুলি প্রয়োজন:

1. একটি GCP অর্গানাইজেশন নোড
2. একটি বিলিং অ্যাকাউন্ট আইডি (আপনার ব্যবহারকারীকে এই বিলিং অ্যাকাউন্টে বিলিং অ্যাডমিন হতে হবে)
3. আপনার ব্যবহারকারীর জন্য সংগঠন স্তরে সংস্থার প্রশাসক IAM ভূমিকা

3. অবকাঠামো সেটআপ - অ্যাডমিন ওয়ার্কফ্লো

এই বিভাগের পদক্ষেপগুলি কর্মশালা তৈরির একজন প্রশাসক দ্বারা সঞ্চালিত হয়।

আপনি যদি ওয়ার্কশপ করছেন এমন একজন ব্যবহারকারী হন, Infrastructure Setup - User Workflow লেবেলযুক্ত পরবর্তী বিভাগে যান

বুটস্ট্র্যাপ ওয়ার্কশপের স্ক্রিপ্ট ব্যাখ্যা করা হয়েছে

bootstrap_workshop.sh নামের একটি স্ক্রিপ্ট ওয়ার্কশপের প্রাথমিক পরিবেশ সেট আপ করতে ব্যবহৃত হয়। আপনি এই স্ক্রিপ্টটি আপনার জন্য একটি একক পরিবেশ বা একাধিক ব্যবহারকারীর জন্য একাধিক পরিবেশ সেট আপ করতে ব্যবহার করতে পারেন যদি আপনি একাধিক ব্যবহারকারীকে প্রশিক্ষণ হিসাবে এই কর্মশালাটি প্রদান করেন।

বুটস্ট্র্যাপ ওয়ার্কশপ স্ক্রিপ্ট ইনপুট হিসাবে নিম্নলিখিত প্রয়োজন:

• প্রতিষ্ঠানের নাম (উদাহরণস্বরূপ yourcompany.com )- এটি সেই প্রতিষ্ঠান যেখানে আপনি কর্মশালার পরিবেশ তৈরি করেন।
• বিলিং আইডি (উদাহরণস্বরূপ 12345-12345-12345 ) - এই বিলিং আইডিটি ওয়ার্কশপের সময় ব্যবহৃত সমস্ত সংস্থান বিল করতে ব্যবহৃত হয়।
• কর্মশালার নম্বর (উদাহরণস্বরূপ 01 ) - একটি দুই অঙ্কের সংখ্যা। আপনি একদিনে একাধিক ওয়ার্কশপ করছেন এবং সেগুলি আলাদাভাবে ট্র্যাক করতে চান এমন ক্ষেত্রে এটি ব্যবহার করা হয়। কর্মশালার নম্বরগুলিও প্রকল্পের আইডি প্রাপ্ত করতে ব্যবহৃত হয়। আলাদা ওয়ার্কশপ নম্বর থাকলে আপনি প্রতিবার অনন্য প্রকল্প আইডি পান তা নিশ্চিত করা সহজ করে তোলে। কর্মশালার নম্বর ছাড়াও, বর্তমান তারিখ ( YYMMDD হিসাবে বিন্যাসিত) প্রকল্প আইডিগুলির জন্যও ব্যবহৃত হয়। তারিখ এবং কর্মশালার সংখ্যার সমন্বয় অনন্য প্রকল্প আইডি প্রদান করে।
• স্টার্ট ইউজার নম্বর (উদাহরণস্বরূপ 1 ) - এই নম্বরটি ওয়ার্কশপে প্রথম ব্যবহারকারীকে নির্দেশ করে। উদাহরণস্বরূপ, যদি আপনি 10 জন ব্যবহারকারীর জন্য একটি ওয়ার্কশপ তৈরি করতে চান, তাহলে আপনার 1-এর প্রারম্ভিক ব্যবহারকারী এবং 10-এর শেষ ব্যবহারকারীর নম্বর থাকতে পারে।
• শেষ ব্যবহারকারীর নম্বর (উদাহরণস্বরূপ 10 ) - এই নম্বরটি ওয়ার্কশপের শেষ ব্যবহারকারীকে নির্দেশ করে। উদাহরণস্বরূপ, আপনি যদি 10 জন ব্যবহারকারীর জন্য একটি ওয়ার্কশপ তৈরি করতে চান, তাহলে আপনার 1-এর প্রারম্ভিক ব্যবহারকারী এবং 10-এর শেষ ব্যবহারকারীর সংখ্যা থাকতে পারে। আপনি যদি একটি একক পরিবেশ (উদাহরণস্বরূপ নিজের জন্য) সেট আপ করেন, তাহলে শুরু করুন এবং শেষ ব্যবহারকারীর সংখ্যা একই। এটি একটি একক পরিবেশ তৈরি করবে।

তারিখ এবং কর্মশালার নম্বর ছাড়াও, শুরু এবং শেষ ব্যবহারকারীর নম্বরগুলিও প্রকল্প আইডিগুলিতে অন্তর্ভুক্ত করা হয়েছে। ব্যবহারকারী আইডি (ওয়ার্কশপ সম্পাদনকারী ব্যবহারকারীদের জন্য) শুরু এবং শেষ ব্যবহারকারীর নম্বর থেকে নেওয়া হয়। ইউজার আইডি User schema and permissions performing the workshop নামের বিভাগে ব্যাখ্যা করা হয়েছে।

• অ্যাডমিন GCS বালতি (উদাহরণস্বরূপ my-gcs-bucket-name ) - একটি GCS বাকেট ওয়ার্কশপ সম্পর্কিত তথ্য সংরক্ষণ করতে ব্যবহৃত হয়। এই তথ্যটি cleanup_workshop.sh স্ক্রিপ্ট দ্বারা বুটস্ট্র্যাপ ওয়ার্কশপ স্ক্রিপ্টের সময় তৈরি করা সমস্ত সংস্থানকে সুন্দরভাবে মুছে ফেলার জন্য ব্যবহার করা হয়। কর্মশালা তৈরির প্রশাসকদের অবশ্যই এই বালতিতে পড়ার/লেখার অনুমতি থাকতে হবে।

বুটস্ট্র্যাপ ওয়ার্কশপ স্ক্রিপ্ট উপরে প্রদত্ত মানগুলি ব্যবহার করে এবং একটি মোড়ক স্ক্রিপ্ট হিসাবে কাজ করে যা setup-terraform-admin-project.sh স্ক্রিপ্টকে কল করে। setup-terraform-admin-project.sh স্ক্রিপ্ট একটি একক ব্যবহারকারীর জন্য কর্মশালার পরিবেশ তৈরি করে।

ওয়ার্কশপ বুটস্ট্র্যাপ করার জন্য অ্যাডমিনের অনুমতি প্রয়োজন

এই কর্মশালায় দুই ধরনের ব্যবহারকারী রয়েছে। একজন ADMIN_USER , যিনি এই কর্মশালার জন্য সংস্থান তৈরি করেন এবং মুছে দেন৷ দ্বিতীয়টি হল MY_USER , যিনি কর্মশালায় পদক্ষেপগুলি সম্পাদন করেন৷ MY_USER শুধুমাত্র নিজস্ব সম্পদে অ্যাক্সেস করতে পারে। ADMIN_USER সমস্ত ব্যবহারকারী সেটআপে অ্যাক্সেস রয়েছে৷ আপনি যদি নিজের জন্য এই সেটআপটি তৈরি করেন, তাহলে ADMIN_USER এবং MY_USER একই। আপনি যদি একাধিক ছাত্রদের জন্য এই কর্মশালা তৈরির একজন প্রশিক্ষক হন, তাহলে আপনার ADMIN_USER এবং MY_USER ভিন্ন হবে৷

ADMIN_USER এর জন্য নিম্নলিখিত সংগঠন স্তরের অনুমতি প্রয়োজন:

• মালিক - সংস্থার সমস্ত প্রকল্পের জন্য প্রকল্প মালিকের অনুমতি৷
• ফোল্ডার অ্যাডমিন - সংস্থায় ফোল্ডার তৈরি এবং মুছে ফেলার ক্ষমতা। প্রতিটি ব্যবহারকারী প্রকল্পের ভিতরে তাদের সমস্ত সংস্থান সহ একটি একক ফোল্ডার পায়।
• সংস্থার প্রশাসক
• প্রকল্প নির্মাতা - সংস্থায় প্রকল্প তৈরি করার ক্ষমতা।
• প্রজেক্ট ডিলিটার - সংস্থার প্রকল্প মুছে ফেলার ক্ষমতা।
• প্রকল্প আইএএম অ্যাডমিন - সংস্থার সমস্ত প্রকল্পে আইএএম নিয়ম তৈরি করার ক্ষমতা।

এগুলি ছাড়াও, ADMIN_USER অবশ্যই কর্মশালার জন্য ব্যবহৃত বিলিং আইডির জন্য বিলিং প্রশাসক হতে হবে৷

কর্মশালা সম্পাদনকারী ব্যবহারকারী স্কিমা এবং অনুমতি

আপনি যদি আপনার প্রতিষ্ঠানের ব্যবহারকারীদের (নিজের ব্যতীত) এই কর্মশালা তৈরি করার পরিকল্পনা করছেন, তাহলে আপনাকে অবশ্যই MY_USERs এর জন্য একটি নির্দিষ্ট ব্যবহারকারীর নামকরণ স্কিম অনুসরণ করতে হবে। bootstrap_workshop.sh স্ক্রিপ্টের সময়, আপনি একটি শুরু এবং একটি শেষ ব্যবহারকারী নম্বর প্রদান করেন। এই সংখ্যাগুলি নিম্নলিখিত ব্যবহারকারীর নাম তৈরি করতে ব্যবহৃত হয়:

• user<3 digit user number>@<organization_name>

উদাহরণ স্বরূপ, আপনি যদি আপনার কোম্পানি ডটকম নামক প্রতিষ্ঠানে স্টার্ট ইউজার নম্বর 1 এবং শেষ ব্যবহারকারী সংখ্যা 3 সহ বুটস্ট্র্যাপ ওয়ার্কশপ স্ক্রিপ্ট চালান, তাহলে নিম্নলিখিত ব্যবহারকারীদের জন্য কর্মশালার পরিবেশ তৈরি করা হয়:

• [e-mail]
• [e-mail]
• [e-mail]

এই ব্যবহারকারীর নামগুলি setup_terraform_admin_project.sh স্ক্রিপ্টের সময় তৈরি করা তাদের নির্দিষ্ট প্রকল্পগুলির জন্য প্রকল্পের মালিকের ভূমিকা বরাদ্দ করা হয়েছে৷ বুটস্ট্র্যাপ স্ক্রিপ্ট ব্যবহার করার সময় আপনাকে অবশ্যই এই ব্যবহারকারীর নামকরণ স্কিমা মেনে চলতে হবে। GSuite-এ একসঙ্গে একাধিক ব্যবহারকারীকে কীভাবে যুক্ত করবেন তা দেখুন।

কর্মশালার জন্য প্রয়োজনীয় সরঞ্জাম

এই কর্মশালাটি ক্লাউড শেল থেকে বুটস্ট্র্যাপ করার উদ্দেশ্যে করা হয়েছে। এই কর্মশালার জন্য নিম্নলিখিত সরঞ্জাম প্রয়োজন.

• gCloud (ver >= 270)
• kubectl
• sed (ক্লাউড শেল/লিনাক্সে সেডের সাথে কাজ করে এবং ম্যাক ওএস নয়)
• গিট (আপ টু ডেট নিশ্চিত করুন)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• কাস্টমাইজ করা

kustomize বাদে সমস্ত টুল ইতিমধ্যেই ক্লাউড শেল-এ ডিফল্টরূপে ইনস্টল করা আছে। kustomize ইনস্টল করা না থাকলে, উপরের লিঙ্কে প্রদত্ত ব্যাশ স্ক্রিপ্ট ব্যবহার করে এটি ইনস্টল করুন এবং kustomize বাইনারি আপনার PATH-এ রয়েছে তা নিশ্চিত করুন এবং ক্লাউড শেল-এ kustomize কমান্ড চালিয়ে নিশ্চিত করুন।

নিজের জন্য ওয়ার্কশপ সেট আপ করুন (একক ব্যবহারকারী সেটআপ)

1. ক্লাউড শেল খুলুন, ক্লাউড শেলে নীচের সমস্ত ক্রিয়া সম্পাদন করুন। নীচের লিঙ্কে ক্লিক করুন.

ক্লাউড শেল

2. আপনি ইচ্ছাকৃত অ্যাডমিন ব্যবহারকারীর সাথে gcloud লগ ইন করেছেন তা যাচাই করুন।

gcloud config list
 

3. একটি WORKDIR তৈরি করুন এবং ওয়ার্কশপের রেপো ক্লোন করুন।

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. কর্মশালার জন্য ব্যবহার করার জন্য আপনার প্রতিষ্ঠানের নাম, বিলিং আইডি, কর্মশালার নম্বর এবং একটি প্রশাসক GCS বাকেট সংজ্ঞায়িত করুন। উপরের বিভাগে ওয়ার্কশপ স্থাপনের জন্য প্রয়োজনীয় অনুমতিগুলি পর্যালোচনা করুন৷

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. bootstrap_workshop.sh স্ক্রিপ্ট চালান। এই স্ক্রিপ্টটি সম্পূর্ণ হতে কয়েক মিনিট সময় নিতে পারে৷

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

মনে রাখবেন যে আপনি নিজের জন্য এটি সেট আপ করার কারণে আপনাকে শুরু এবং শেষ ব্যবহারকারীর সংখ্যা নির্ধারণ করার দরকার নেই৷

bootstrap_workshop.sh স্ক্রিপ্ট সম্পূর্ণ হওয়ার পরে, প্রতিষ্ঠানের মধ্যে প্রতিটি ব্যবহারকারীর জন্য একটি GCP ফোল্ডার তৈরি করা হয়। ফোল্ডারের মধ্যে, একটি টেরাফর্ম অ্যাডমিন প্রকল্প তৈরি করা হয়েছে। এই ওয়ার্কশপের জন্য প্রয়োজনীয় GCP রিসোর্সের অবশিষ্টাংশ তৈরি করতে টেরাফর্ম অ্যাডমিন প্রজেক্ট ব্যবহার করা হয়। আপনি টেরাফর্ম অ্যাডমিন প্রকল্পে প্রয়োজনীয় API গুলি সক্ষম করুন৷ টেরাফর্ম প্ল্যান প্রয়োগ করতে আপনি ক্লাউড বিল্ড ব্যবহার করেন। আপনি ক্লাউড বিল্ড পরিষেবা অ্যাকাউন্টটিকে সঠিক IAM ভূমিকা দিন যাতে এটি GCP-তে সংস্থান তৈরি করতে সক্ষম হয়। শেষ পর্যন্ত আপনি সমস্ত GCP সংস্থানগুলির জন্য টেরাফর্ম স্টেটগুলি সংরক্ষণ করতে একটি Google ক্লাউড স্টোরেজ (GCS) বালতিতে একটি দূরবর্তী ব্যাকএন্ড কনফিগার করুন৷

টেরাফর্ম অ্যাডমিন প্রোজেক্টে ক্লাউড বিল্ড কাজগুলি দেখার জন্য, আপনার টেরাফর্ম অ্যাডমিন প্রোজেক্ট আইডি প্রয়োজন। এটি আপনার asm ডিরেক্টরির অধীনে vars/vars.sh ফাইলে সংরক্ষণ করা হয়। আপনি প্রশাসক হিসাবে নিজের জন্য ওয়ার্কশপ সেট আপ করলেই এই ডিরেক্টরিটি বজায় থাকবে।

6. পরিবেশের ভেরিয়েবল সেট করতে ভেরিয়েবল ফাইলটি উৎস করুন

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

একাধিক ব্যবহারকারীর জন্য ওয়ার্কশপ সেট আপ করুন (মাল্টি ইউজার সেটআপ)

7. ক্লাউড শেল খুলুন, ক্লাউড শেলে নীচের সমস্ত ক্রিয়া সম্পাদন করুন। নীচের লিঙ্কে ক্লিক করুন.

ক্লাউড শেল

8. আপনি ইচ্ছাকৃত অ্যাডমিন ব্যবহারকারীর সাথে gcloud লগ ইন করেছেন তা যাচাই করুন।

gcloud config list
 

9. একটি WORKDIR তৈরি করুন এবং ওয়ার্কশপের রেপো ক্লোন করুন।

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. কর্মশালার জন্য ব্যবহার করার জন্য আপনার প্রতিষ্ঠানের নাম, বিলিং আইডি, কর্মশালার নম্বর, শুরু এবং শেষ ব্যবহারকারীর নম্বর এবং একটি প্রশাসক GCS বাকেট সংজ্ঞায়িত করুন। উপরের বিভাগে ওয়ার্কশপ স্থাপনের জন্য প্রয়োজনীয় অনুমতিগুলি পর্যালোচনা করুন৷

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. bootstrap_workshop.sh স্ক্রিপ্ট চালান। এই স্ক্রিপ্টটি সম্পূর্ণ হতে কয়েক মিনিট সময় নিতে পারে৷

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. টেরাফর্ম প্রকল্প আইডি পুনরুদ্ধার করতে প্রশাসক GCS বাকেট থেকে workshop.txt ফাইলটি পান।

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. ল্যাব সেটআপ এবং প্রস্তুতি

কর্মশালা সঞ্চালন ব্যবহারকারীরা এখানে শুরু. ক্রোম বা ফায়ারফক্সে একটি INCOGNITO উইন্ডো থেকে সমস্ত পদক্ষেপগুলি সম্পাদন করুন৷

আপনার ল্যাব পাথ চয়ন করুন

এই কর্মশালার ল্যাব দুটি উপায়ে সঞ্চালিত হতে পারে:

• " সহজ দ্রুত ট্র্যাক ইন্টারেক্টিভ স্ক্রিপ্ট " উপায়
• " প্রতিটি নির্দেশ ম্যানুয়াল কপি এবং পেস্ট " উপায়

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

ফাস্ট ট্র্যাক স্ক্রিপ্টগুলি নীচে দেখানো হিসাবে প্রতিটি ল্যাবের উপরে একটি সবুজ বাক্সে প্রদর্শিত হবে।

ফাস্ট ট্র্যাক স্ক্রিপ্ট

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

কপি-এবং-পেস্ট পদ্ধতি হল কমান্ডের ব্যাখ্যা সহ পৃথক কমান্ড ব্লক কপি-এবং-পেস্ট করার প্রথাগত উপায়। এই পদ্ধতি শুধুমাত্র একবার চালানোর উদ্দেশ্যে করা হয়. কোন গ্যারান্টি নেই যে এই পদ্ধতিতে পুনরায় চালানো কমান্ডগুলি আপনাকে একই ফলাফল দেবে।

ল্যাবগুলি সম্পাদন করার সময়, অনুগ্রহ করে দুটি পদ্ধতির মধ্যে একটি বেছে নিন।

আপনি একটি পদ্ধতি বেছে নেওয়ার পরে এবং সেই পদ্ধতিতে পদক্ষেপগুলি সম্পাদন করার পরে, অন্য পদ্ধতিতে পদক্ষেপগুলি সম্পাদন করবেন না।

ফাস্ট ট্র্যাক স্ক্রিপ্ট সেটআপ

আপনি দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পূর্ণ করার পরে, আপনি সেই ল্যাবটি দিয়ে শেষ করেছেন। কপি-এন্ড-পেস্ট ল্যাব নির্দেশাবলীতে পদক্ষেপগুলি সম্পাদন করবেন না।

ব্যবহারকারীর তথ্য পান

এই কর্মশালাটি কর্মশালার প্রশাসক দ্বারা তৈরি একটি অস্থায়ী ব্যবহারকারী অ্যাকাউন্ট (বা একটি ল্যাব অ্যাকাউন্ট) ব্যবহার করে সঞ্চালিত হয়। ল্যাব অ্যাকাউন্ট ওয়ার্কশপের সমস্ত প্রকল্পের মালিক। ওয়ার্কশপ অ্যাডমিনিস্ট্রেটর ওয়ার্কশপ সম্পাদনকারী ব্যবহারকারীকে ল্যাব অ্যাকাউন্টের শংসাপত্র (ব্যবহারকারীর নাম এবং পাসওয়ার্ড) প্রদান করে। ব্যবহারকারীর সমস্ত প্রকল্প ল্যাব অ্যাকাউন্টের ব্যবহারকারীর নাম দ্বারা প্রিফিক্স করা হয়েছে উদাহরণস্বরূপ ল্যাব অ্যাকাউন্ট [e-mail] এর জন্য, টেরাফর্ম অ্যাডমিন প্রকল্প আইডি হবে user001-200131-01-tf-abcde এবং বাকি প্রকল্পগুলির জন্য। প্রতিটি ব্যবহারকারীকে অবশ্যই ওয়ার্কশপ অ্যাডমিনিস্ট্রেটরের দেওয়া ল্যাব অ্যাকাউন্ট দিয়ে লগ ইন করতে হবে এবং ল্যাব অ্যাকাউন্ট ব্যবহার করে ওয়ার্কশপটি সম্পাদন করতে হবে।

আপনার কর্পোরেট ইমেল পরীক্ষা করুন (একই ইমেল যা আপনি কর্মশালায় নিবন্ধন করতে ব্যবহার করেছিলেন)। আপনার ল্যাব অ্যাকাউন্টের শংসাপত্র (যেমন ব্যবহারকারীর নাম এবং পাসওয়ার্ড) সহ ওয়ার্কশপ অ্যাডমিনের কাছ থেকে একটি ইমেল পাওয়া উচিত ছিল৷ ইমেইল এই মত দেখায়.

1. নীচের লিঙ্কে ক্লিক করে ক্লাউড শেল খুলুন।

ক্লাউড শেল

2. ল্যাব অ্যাকাউন্টের শংসাপত্র দিয়ে লগ ইন করুন (আপনার কর্পোরেট বা ব্যক্তিগত অ্যাকাউন্ট দিয়ে লগ ইন করবেন না)। ল্যাব অ্যাকাউন্টটি userXYZ@<workshop_domain>.com এর মত দেখাচ্ছে।
3. যেহেতু এটি একটি নতুন অ্যাকাউন্ট, তাই আপনাকে Google পরিষেবার শর্তাবলী মেনে নিতে বলা হচ্ছে৷ স্বীকার করুন ক্লিক করুন.

4. পরবর্তী স্ক্রিনে, Google পরিষেবার শর্তাবলীতে সম্মত হতে চেকবক্সটি নির্বাচন করুন এবং Start Cloud Shell ক্লিক করুন৷

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

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. এই কর্মশালার জন্য ব্যবহার করার জন্য একটি পরিবর্তনশীল হিসাবে ল্যাব অ্যাকাউন্ট ব্যবহারকারীকে রপ্তানি করুন। এটি সেই একই অ্যাকাউন্ট যা দিয়ে আপনি ক্লাউড শেলে লগ ইন করেছেন।

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

দ্রষ্টব্য: আপনি যদি একজন প্রশাসক হন এবং "-সুফা" বা "-সেটআপ-ফর-অ্যাডমিন" ফ্ল্যাগগুলি ব্যবহার করে নিজের জন্য ওয়ার্কশপ সেট আপ করেন তাহলে আপনি ওয়ার্কশপ প্রকল্পগুলি তৈরি করতে যে জিসিপি অ্যাকাউন্ট ব্যবহার করেছিলেন তার ইমেলে MY_USER সেট করুন৷

7. WORKDIR এবং MY_USER ভেরিয়েবলগুলিকে ইকো করুন যাতে নিম্নলিখিত কমান্ডগুলি চালানোর মাধ্যমে উভয়ই সঠিকভাবে সেট করা হয়েছে।

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. কর্মশালার রেপো ক্লোন করুন।

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. অবকাঠামো সেটআপ - ব্যবহারকারীর কর্মপ্রবাহ

উদ্দেশ্য: পরিকাঠামো এবং Istio ইনস্টলেশন যাচাই করুন

• কর্মশালার সরঞ্জাম ইনস্টল করুন
• ক্লোন ওয়ার্কশপ রেপো
• Infrastructure ইনস্টল যাচাই করুন
• k8s-repo ইনস্টল যাচাই করুন
• Istio ইনস্টলেশন যাচাই করুন

ফাস্ট ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি বেছে নেন, এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

স্ক্রিপ্ট সম্পূর্ণ হওয়ার পরে, আপনার ক্লাউড শেল সেশনে ভেরিয়েবলগুলি আপডেট করতে আপনার bashrc উৎস করুন।

source ${HOME}/.bashrc

কপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

গুরুত্বপূর্ণ: আপনি যদি ইতিমধ্যেই এই ল্যাবের জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পূর্ণ করে থাকেন, তাহলে নীচের কপি-অ্যান্ড-পেস্ট পদ্ধতিটি সম্পাদন করবেন না**।**

ব্যবহারকারীর তথ্য পান

ওয়ার্কশপ স্থাপনকারী প্রশাসককে ব্যবহারকারীকে ব্যবহারকারীর নাম এবং পাসওয়ার্ড তথ্য সরবরাহ করতে হবে। ব্যবহারকারীর সমস্ত প্রকল্প ব্যবহারকারীর নামের দ্বারা উপসর্গযুক্ত হবে উদাহরণস্বরূপ [e-mail] ব্যবহারকারীর জন্য, টেরাফর্ম অ্যাডমিন প্রকল্প আইডি হবে user001-200131-01-tf-abcde এবং বাকি প্রকল্পগুলির জন্য। প্রতিটি ব্যবহারকারীর শুধুমাত্র তাদের নিজস্ব কর্মশালার পরিবেশে অ্যাক্সেস আছে।

কর্মশালার জন্য প্রয়োজনীয় সরঞ্জাম

এই কর্মশালাটি ক্লাউড শেল থেকে বুটস্ট্র্যাপ করার উদ্দেশ্যে করা হয়েছে। এই কর্মশালার জন্য নিম্নলিখিত সরঞ্জাম প্রয়োজন.

kustomize এবং pv ব্যতীত সমস্ত সরঞ্জাম ইতিমধ্যেই ক্লাউড শেল-এ ডিফল্টরূপে ইনস্টল করা আছে। আপনি নীচে তাদের উভয় ইনস্টল করার নির্দেশাবলী পাবেন।

• gCloud (ver >= 270)
• kubectl
• sed (ক্লাউড শেল/লিনাক্সে সেডের সাথে কাজ করে এবং ম্যাক ওএস নয়)
• গিট (আপ টু ডেট নিশ্চিত করুন)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• কাস্টমাইজ করা
• pv

টেরফর্ম অ্যাডমিন প্রকল্প অ্যাক্সেস করুন

bootstrap_workshop.sh স্ক্রিপ্ট সম্পূর্ণ হওয়ার পরে, প্রতিষ্ঠানের মধ্যে প্রতিটি ব্যবহারকারীর জন্য একটি GCP ফোল্ডার তৈরি করা হয়। ফোল্ডারের মধ্যে, একটি টেরাফর্ম অ্যাডমিন প্রকল্প তৈরি করা হয়েছে। এই ওয়ার্কশপের জন্য প্রয়োজনীয় GCP রিসোর্সের অবশিষ্টাংশ তৈরি করতে টেরাফর্ম অ্যাডমিন প্রজেক্ট ব্যবহার করা হয়। setup-terraform-admin-project.sh স্ক্রিপ্ট টেরাফর্ম অ্যাডমিন প্রকল্পে প্রয়োজনীয় API গুলিকে সক্ষম করে৷ ক্লাউড বিল্ড ব্যবহার করা হয় Terraform পরিকল্পনা প্রয়োগ করতে। স্ক্রিপ্টের মাধ্যমে, আপনি ক্লাউড বিল্ড পরিষেবা অ্যাকাউন্টকে সঠিক IAM ভূমিকা প্রদান করেন যাতে এটি GCP-তে সংস্থান তৈরি করতে সক্ষম হয়। সবশেষে, সমস্ত GCP সংস্থানগুলির জন্য Terraform রাজ্যগুলি সঞ্চয় করার জন্য একটি Google ক্লাউড স্টোরেজ (GCS) বালতিতে একটি দূরবর্তী ব্যাকএন্ড কনফিগার করা হয়েছে৷

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

এই কর্মশালাটি ক্লাউড শেল এবং ক্লাউড কনসোলে সঞ্চালিত হওয়ার উদ্দেশ্যে করা হয়েছে৷ একটি INCOGNITO উইন্ডোতে নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করুন যেহেতু আপনি একটি পৃথক ব্যবহারকারীর নাম এবং পাসওয়ার্ড দিয়ে লগ ইন করবেন৷

1. নীচের লিঙ্কে ক্লিক করে ক্লাউড শেল খুলুন (যদি এটি ইতিমধ্যে ল্যাব সেটআপ এবং প্রস্তুতি বিভাগ থেকে খোলা না থাকে)।

ক্লাউড শেল

2. $HOME/bin ফোল্ডারে kustomize (যদি ইতিমধ্যে ইনস্টল না করা থাকে) ইনস্টল করুন এবং $PATH-এ $HOME/bin ফোল্ডার যোগ করুন।

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. pv ইনস্টল করুন এবং এটিকে $HOME/bin/pv এ সরান।

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. আপনার ব্যাশ প্রম্পট আপডেট করুন।

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. আপনি উদ্দিষ্ট ব্যবহারকারী অ্যাকাউন্ট দিয়ে gcloud এ লগ ইন করেছেন তা যাচাই করুন।

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. নিম্নলিখিত কমান্ড চালানোর মাধ্যমে আপনার Terraform অ্যাডমিন প্রকল্প আইডি পান:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. ওয়ার্কশপের সাথে যুক্ত সমস্ত সংস্থান টেরাফর্ম অ্যাডমিন প্রজেক্টের একটি GCS বাকেটের মধ্যে সংরক্ষিত একটি vars.sh ফাইলে ভেরিয়েবল হিসাবে সংরক্ষণ করা হয়। আপনার terraform অ্যাডমিন প্রকল্পের জন্য vars.sh ফাইলটি পান।

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Terraform অ্যাডমিন প্রকল্পের জন্য ক্লাউড বিল্ড পৃষ্ঠা খুলতে প্রদর্শিত লিঙ্কটিতে ক্লিক করুন এবং বিল্ডটি সফলভাবে সম্পন্ন হয়েছে তা যাচাই করুন।

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

প্রথমবার ক্লাউড কনসোল অ্যাক্সেস করলে, Google পরিষেবার শর্তাবলীতে সম্মত হন।

9. এখন আপনি ক্লাউড বিল্ড পৃষ্ঠাটি দেখছেন, বাম হাতের নেভিগেশন থেকে History লিঙ্কে ক্লিক করুন এবং প্রারম্ভিক Terraform প্রয়োগের বিশদ বিবরণ দেখতে সর্বশেষ বিল্ডে ক্লিক করুন। নিম্নলিখিত সংস্থানগুলি টেরাফর্ম স্ক্রিপ্টের অংশ হিসাবে তৈরি করা হয়েছে। আপনি উপরের আর্কিটেকচার ডায়াগ্রামটিও উল্লেখ করতে পারেন।

• প্রতিষ্ঠানে 4টি জিসিপি প্রকল্প। প্রদত্ত বিলিং অ্যাকাউন্ট প্রতিটি প্রকল্পের সাথে যুক্ত।
• একটি প্রকল্প হল শেয়ার্ড ভিপিসির জন্য network host project । এই প্রকল্পে অন্য কোন সম্পদ তৈরি করা হয় না।
• একটি প্রকল্প হল Istio কন্ট্রোল প্লেন GKE ক্লাস্টারগুলির জন্য ব্যবহৃত ops project ।
• দুটি প্রকল্প তাদের নিজ নিজ পরিষেবাতে কাজ করা দুটি ভিন্ন উন্নয়ন দলের প্রতিনিধিত্ব করে।
• তিনটি ops , dev1 এবং dev2 প্রকল্পের প্রতিটিতে দুটি GKE ক্লাস্টার তৈরি করা হয়েছে।
• k8s-repo নামে একটি CSR রেপো তৈরি করা হয়েছে যাতে Kubernetes ম্যানিফেস্ট ফাইলগুলির জন্য ছয়টি ফোল্ডার রয়েছে। GKE ক্লাস্টার প্রতি একটি ফোল্ডার। এই রেপোটি GitOps ফ্যাশনে ক্লাস্টারে কুবারনেটস ম্যানিফেস্ট স্থাপন করতে ব্যবহৃত হয়।
• একটি ক্লাউড বিল্ড ট্রিগার তৈরি করা হয়েছে যাতে k8s-repo এর মাস্টার শাখার প্রতি প্রতিশ্রুতি দেওয়া হলে, এটি তাদের নিজ নিজ ফোল্ডার থেকে GKE ক্লাস্টারে Kubernetes ম্যানিফেস্ট স্থাপন করে।

টেরাফর্ম স্ক্রিপ্টটি 40-50 মিনিট সময় নেয়।

10. terraform admin project বিল্ড শেষ হলে অপস প্রোজেক্টে আরেকটি বিল্ড শুরু হবে। ops project জন্য ক্লাউড বিল্ড পৃষ্ঠা খুলতে প্রদর্শিত লিঙ্কটিতে ক্লিক করুন এবং k8s-রেপো ক্লাউড বিল্ড সফলভাবে সমাপ্ত হয়েছে কিনা তা যাচাই করুন।

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

দ্রষ্টব্য: আপনি Istio ইনস্টলেশন যাচাই করার আগে এই বিল্ডটি সম্পূর্ণ করতে হবে।

ইনস্টলেশন যাচাই করুন

11. সমস্ত ক্লাস্টারের জন্য kubeconfig ফাইল তৈরি করুন। নিম্নলিখিত স্ক্রিপ্ট চালান.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

এই স্ক্রিপ্টটি kubemesh নামক gke ফোল্ডারে একটি নতুন kubeconfig ফাইল তৈরি করে।

12. নতুন kubeconfig ফাইলের দিকে নির্দেশ করতে KUBECONFIG ভেরিয়েবল পরিবর্তন করুন।

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. ক্লাউড শেল-এর .bashrc-এ vars.sh এবং KUBECONFIG var যোগ করুন যাতে প্রতিবার ক্লাউড শেল রিস্টার্ট করা হয়।

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. আপনার ক্লাস্টার প্রসঙ্গ তালিকাভুক্ত করুন. আপনি ছয় ক্লাস্টার দেখতে হবে.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Istio ইনস্টলেশন যাচাই করুন

15. সমস্ত পড চলছে এবং কাজ শেষ হয়েছে তা পরীক্ষা করে উভয় ক্লাস্টারে ইস্টিও ইনস্টল করা আছে তা নিশ্চিত করুন।

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. উভয় dev1 ক্লাস্টারে Istio ইনস্টল করা আছে তা নিশ্চিত করুন। শুধুমাত্র Citadel, sidecar-injector এবং coredns dev1 ক্লাস্টারে চলে। তারা ops-1 ক্লাস্টারে চলমান একটি ইস্টিও কন্ট্রোলপ্লেন শেয়ার করে।

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. উভয় dev2 ক্লাস্টারে Istio ইনস্টল করা আছে তা নিশ্চিত করুন। শুধুমাত্র Citadel, sidecar-injector এবং coredns dev2 ক্লাস্টারে চলে। তারা ops-2 ক্লাস্টারে চলমান একটি ইস্টিও কন্ট্রোলপ্লেন শেয়ার করে।

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

শেয়ার্ড কন্ট্রোল প্লেনের জন্য পরিষেবা আবিষ্কার যাচাই করুন

18. ঐচ্ছিকভাবে, গোপনীয়তা স্থাপন করা হয়েছে যাচাই করুন।

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

এই কর্মশালায়, আপনি একটি একক ভাগ করা VPC ব্যবহার করেন যাতে সমস্ত GKE ক্লাস্টার তৈরি করা হয়। ক্লাস্টার জুড়ে পরিষেবাগুলি আবিষ্কার করতে, আপনি অপস ক্লাস্টারগুলিতে গোপনীয়তা হিসাবে তৈরি kubeconfig ফাইলগুলি (প্রতিটি অ্যাপ্লিকেশন ক্লাস্টারের জন্য) ব্যবহার করেন। পাইলট অ্যাপ্লিকেশন ক্লাস্টারগুলির কুবে এপিআই সার্ভারকে জিজ্ঞাসা করে পরিষেবাগুলি আবিষ্কার করতে এই গোপনীয়তাগুলি ব্যবহার করে (উপরের গোপনীয়তার মাধ্যমে প্রমাণীকৃত)। আপনি দেখতে পাচ্ছেন যে উভয় অপ্স ক্লাস্টারই kubeconfig-তৈরি গোপনীয়তা ব্যবহার করে সমস্ত অ্যাপ ক্লাস্টারে প্রমাণীকরণ করতে পারে। অপস ক্লাস্টারগুলি গোপন পদ্ধতি হিসাবে kubeconfig ফাইলগুলি ব্যবহার করে স্বয়ংক্রিয়ভাবে পরিষেবাগুলি আবিষ্কার করতে পারে। এর জন্য অপস ক্লাস্টারে থাকা পাইলটের অন্য সমস্ত ক্লাস্টারের Kube API সার্ভারে অ্যাক্সেস থাকা প্রয়োজন। পাইলট যদি Kube API সার্ভারগুলিতে পৌঁছাতে না পারে, তাহলে আপনি ম্যানুয়ালি রিমোট পরিষেবাগুলিকে ServiceEntry হিসাবে যোগ করবেন। আপনি আপনার পরিষেবা রেজিস্ট্রিতে সার্ভিস এন্ট্রিগুলিকে DNS এন্ট্রি হিসাবে ভাবতে পারেন। সার্ভিস এন্ট্রিগুলি একটি সম্পূর্ণ যোগ্য DNS নাম ( FQDN ) এবং একটি IP ঠিকানা ব্যবহার করে একটি পরিষেবাকে সংজ্ঞায়িত করে যেখানে এটি পৌঁছানো যেতে পারে। আরও তথ্যের জন্য Istio মাল্টিক্লাস্টার ডক্স দেখুন।

6. ইনফ্রাস্ট্রাকচার রেপো ব্যাখ্যা করা হয়েছে

অবকাঠামো ক্লাউড বিল্ড

কর্মশালার জন্য GCP সংস্থানগুলি ক্লাউড বিল্ড এবং একটি infrastructure CSR রেপো ব্যবহার করে তৈরি করা হয়েছে৷ আপনি শুধু আপনার স্থানীয় টার্মিনাল থেকে একটি বুটস্ট্র্যাপ স্ক্রিপ্ট ( scripts/bootstrap_workshop.sh এ অবস্থিত) চালিয়েছেন। বুটস্ট্র্যাপ স্ক্রিপ্ট একটি GCP ফোল্ডার, একটি টেরাফর্ম অ্যাডমিন প্রকল্প এবং ক্লাউড বিল্ড পরিষেবা অ্যাকাউন্টের জন্য উপযুক্ত IAM অনুমতি তৈরি করে। টেরাফর্ম অ্যাডমিন প্রজেক্ট টেরাফর্ম স্টেট, লগ এবং বিবিধ স্ক্রিপ্ট সংরক্ষণ করতে ব্যবহৃত হয়। এতে infrastructure এবং k8s_repo CSR রেপো রয়েছে। এই রেপোগুলি পরবর্তী বিভাগে বিশদভাবে ব্যাখ্যা করা হয়েছে। টেরাফর্ম অ্যাডমিন প্রকল্পে অন্য কোন কর্মশালার সংস্থান তৈরি করা হয় না। টেরাফর্ম অ্যাডমিন প্রকল্পের ক্লাউড বিল্ড পরিষেবা অ্যাকাউন্টটি ওয়ার্কশপের জন্য সংস্থান তৈরি করতে ব্যবহৃত হয়।

infrastructure ফোল্ডারে অবস্থিত একটি cloudbuild.yaml ফাইল ওয়ার্কশপের জন্য GCP সংস্থান তৈরি করতে ব্যবহৃত হয়। এটি GCP সংস্থান তৈরি করতে প্রয়োজনীয় সমস্ত সরঞ্জাম সহ একটি কাস্টম নির্মাতা চিত্র তৈরি করে। এই টুলগুলির মধ্যে রয়েছে gcloud SDK, terraform এবং অন্যান্য ইউটিলিটি যেমন python, git, jq ইত্যাদি। কাস্টম বিল্ডার ইমেজ terraform plan চালায় এবং প্রতিটি রিসোর্সের জন্য apply । প্রতিটি সংস্থানের টেরাফর্ম ফাইলগুলি পৃথক ফোল্ডারে অবস্থিত (পরবর্তী বিভাগে বিশদ বিবরণ)। রিসোর্সগুলি এক সময়ে তৈরি করা হয় এবং সেগুলি সাধারণত কীভাবে তৈরি করা হবে তার ক্রমানুসারে (উদাহরণস্বরূপ, প্রকল্পে সংস্থান তৈরি করার আগে একটি GCP প্রকল্প তৈরি করা হয়)। আরো বিস্তারিত জানার জন্য cloudbuild.yaml ফাইল পর্যালোচনা করুন.

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

ফোল্ডার গঠন - দল, পরিবেশ এবং সম্পদ

ইনফ্রাস্ট্রাকচার রেপো ওয়ার্কশপের জন্য GCP অবকাঠামো সংস্থান সেট আপ করে। এটি ফোল্ডার এবং সাবফোল্ডারে গঠন করা হয়। রেপোর মধ্যে বেস ফোল্ডারগুলি নির্দিষ্ট GCP সংস্থানগুলির মালিক team প্রতিনিধিত্ব করে। ফোল্ডারের পরবর্তী স্তরটি দলের জন্য নির্দিষ্ট environment প্রতিনিধিত্ব করে (উদাহরণস্বরূপ dev, stage, prod)। এনভায়রনমেন্টের মধ্যে ফোল্ডারগুলির পরবর্তী স্তরটি নির্দিষ্ট resource প্রতিনিধিত্ব করে (উদাহরণস্বরূপ host_project, gke_clusters ইত্যাদি)। প্রয়োজনীয় স্ক্রিপ্ট এবং টেরাফর্ম ফাইল রিসোর্স ফোল্ডারের মধ্যে বিদ্যমান।

এই কর্মশালায় নিম্নলিখিত চার ধরনের দলকে প্রতিনিধিত্ব করা হয়:

1. পরিকাঠামো - ক্লাউড অবকাঠামো দলের প্রতিনিধিত্ব করে। তারা অন্য সব দলের জন্য GCP সম্পদ তৈরি করার জন্য দায়ী। তারা তাদের সম্পদের জন্য Terraform অ্যাডমিন প্রকল্প ব্যবহার করে। ইনফ্রাস্ট্রাকচার রেপো নিজেই টেরাফর্ম অ্যাডমিন প্রজেক্টে রয়েছে, সেইসাথে টেরাফর্ম স্টেট ফাইল (নীচে ব্যাখ্যা করা হয়েছে)। এই সংস্থানগুলি বুটস্ট্র্যাপ প্রক্রিয়া চলাকালীন একটি ব্যাশ স্ক্রিপ্ট দ্বারা তৈরি করা হয় (বিশদ বিবরণের জন্য মডিউল 0 - অ্যাডমিনিস্ট্রেটর ওয়ার্কফ্লো দেখুন)।
2. নেটওয়ার্ক - নেটওয়ার্কিং দলের প্রতিনিধিত্ব করে। তারা VPC এবং নেটওয়ার্কিং সংস্থানগুলির জন্য দায়ী। তারা নিম্নলিখিত GCP সম্পদের মালিক।
3. host project - শেয়ার্ড ভিপিসি হোস্ট প্রোজেক্টের প্রতিনিধিত্ব করে।
4. shared VPC - শেয়ার্ড ভিপিসি, সাবনেট, সেকেন্ডারি আইপি রেঞ্জ, রুট এবং ফায়ারওয়াল নিয়ম উপস্থাপন করে।
5. ops - অপারেশন/ডিভপস দলকে প্রতিনিধিত্ব করে। তারা নিম্নলিখিত সম্পদের মালিক।
6. ops project - সমস্ত অপস রিসোর্সের জন্য একটি প্রজেক্ট উপস্থাপন করে।
7. gke clusters - অঞ্চল প্রতি একটি ops GKE ক্লাস্টার। Istio কন্ট্রোল প্লেন প্রতিটি ops GKE ক্লাস্টারে ইনস্টল করা আছে।
8. k8s-repo - একটি CSR রেপো যাতে সমস্ত GKE ক্লাস্টারের জন্য GKE মেনিফেস্ট থাকে।
9. apps - অ্যাপ্লিকেশন টিম প্রতিনিধিত্ব করে। এই কর্মশালাটি app1 এবং app2 নামে দুটি দলকে অনুকরণ করে। তারা নিম্নলিখিত সম্পদের মালিক।
10. app projects - প্রতিটি অ্যাপ দল তাদের নিজস্ব প্রকল্পের সেট পায়। এটি তাদের নির্দিষ্ট প্রকল্পের জন্য বিলিং এবং IAM নিয়ন্ত্রণ করতে দেয়।
11. gke clusters - এগুলি হল অ্যাপ্লিকেশন ক্লাস্টার যেখানে অ্যাপ্লিকেশন কন্টেইনার/পডগুলি চলে৷
12. gce instances - ঐচ্ছিকভাবে, যদি তাদের কাছে এমন অ্যাপ্লিকেশন থাকে যা GCE দৃষ্টান্তে চলে। এই কর্মশালায়, app1-এর কয়েকটি GCE উদাহরণ রয়েছে যেখানে অ্যাপ্লিকেশনটির কিছু অংশ চলে।

এই কর্মশালায়, একই অ্যাপ (হিপস্টার শপ অ্যাপ) অ্যাপ1 এবং অ্যাপ2 উভয়ের প্রতিনিধিত্ব করে।

প্রদানকারী, রাজ্য এবং আউটপুট - ব্যাকএন্ড এবং ভাগ করা রাজ্য

google এবং google-beta প্রদানকারীরা gcp/[environment]/gcp/provider.tf এ অবস্থিত। provider.tf ফাইলটি প্রতিটি রিসোর্স ফোল্ডারে সিমলিংক করা আছে। এটি আপনাকে প্রতিটি সংস্থানের জন্য পৃথকভাবে সরবরাহকারীদের পরিচালনার পরিবর্তে এক জায়গায় প্রদানকারীকে পরিবর্তন করতে দেয়৷

প্রতিটি সম্পদে একটি backend.tf ফাইল থাকে যা সম্পদের tfstate ফাইলের অবস্থান নির্ধারণ করে। এই backend.tf ফাইলটি একটি টেমপ্লেট থেকে তৈরি করা হয়েছে ( templates/backend.tf_tmpl এ অবস্থিত) একটি স্ক্রিপ্ট ব্যবহার করে ( scripts/setup_terraform_admin_project এ অবস্থিত) এবং তারপর সংশ্লিষ্ট রিসোর্স ফোল্ডারে রাখা হয়েছে। Google ক্লাউড স্টোরেজ (GCS) বালতি ব্যাকএন্ডের জন্য ব্যবহার করা হয়। GCS বাকেট ফোল্ডারের নাম রিসোর্সের নামের সাথে মেলে। সমস্ত রিসোর্স ব্যাকএন্ড টেরাফর্ম অ্যাডমিন প্রোজেক্টে থাকে।

আন্তঃনির্ভরশীল মানের সম্পদে একটি output.tf ফাইল থাকে। প্রয়োজনীয় আউটপুট মানগুলি সেই নির্দিষ্ট সংস্থানের জন্য ব্যাকএন্ডে সংজ্ঞায়িত tfstate ফাইলে সংরক্ষণ করা হয়। উদাহরণস্বরূপ, একটি প্রকল্পে একটি GKE ক্লাস্টার তৈরি করতে, আপনাকে প্রকল্প আইডি জানতে হবে। প্রকল্প আইডি output.tf এর মাধ্যমে tfstate ফাইলে আউটপুট করা হয় যা GKE ক্লাস্টার রিসোর্সে একটি terraform_remote_state ডেটা উৎসের মাধ্যমে ব্যবহার করা যেতে পারে।

শেয়ার্ড_স্টেট ফাইলটি একটি terraform_remote_state ডেটা উৎস যা একটি রিসোর্সের tfstate ফাইলের দিকে নির্দেশ করে। একটি shared_state_[resource_name].tf ফাইল (বা ফাইল) রিসোর্স ফোল্ডারে বিদ্যমান যার জন্য অন্যান্য রিসোর্স থেকে আউটপুট প্রয়োজন। উদাহরণস্বরূপ, ops_gke রিসোর্স ফোল্ডারে, ops_project এবং shared_vpc রিসোর্স থেকে শেয়ার্ড_স্টেট ফাইল রয়েছে, কারণ ops প্রোজেক্টে GKE ক্লাস্টার তৈরি করতে আপনার প্রোজেক্ট আইডি এবং VPC বিশদ প্রয়োজন। শেয়ার্ড_স্টেট ফাইলগুলি একটি টেমপ্লেট থেকে তৈরি করা হয় ( templates/shared_state.tf_tmpl এ অবস্থিত) একটি স্ক্রিপ্ট ব্যবহার করে ( scripts/setup_terraform_admin_project এ অবস্থিত)। সমস্ত সম্পদের শেয়ার্ড_স্টেট ফাইলগুলি gcp/[environment]/shared_states ফোল্ডারে রাখা হয়। প্রয়োজনীয় শেয়ার্ড_স্টেট ফাইলগুলি সংশ্লিষ্ট রিসোর্স ফোল্ডারে সিমলিঙ্ক করা হয়েছে। শেয়ার্ড_স্টেট ফাইলগুলির একটি ফোল্ডারে স্থাপন করা এবং উপযুক্ত সংস্থান ফোল্ডারে সেগুলিকে সিম লিঙ্ক করা সমস্ত স্টেট ফাইলগুলিকে এক জায়গায় পরিচালনা করা সহজ করে তোলে।

ভেরিয়েবল

সমস্ত সম্পদ মান পরিবেশের ভেরিয়েবল হিসাবে সংরক্ষণ করা হয়। এই ভেরিয়েবলগুলি টেরাফর্ম অ্যাডমিন প্রোজেক্টের একটি GCS বাকেটের মধ্যে অবস্থিত vars.sh নামক একটি ফাইলে (রপ্তানি বিবৃতি হিসাবে) সংরক্ষণ করা হয়। এতে প্রতিষ্ঠানের আইডি, বিলিং অ্যাকাউন্ট, প্রোজেক্ট আইডি, জিকেই ক্লাস্টারের বিবরণ ইত্যাদি রয়েছে। আপনার সেটআপের মান পেতে আপনি যেকোনো টার্মিনাল থেকে vars.sh ডাউনলোড এবং উৎস করতে পারেন।

Terraform ভেরিয়েবলগুলি vars.sh এ TF_VAR_[variable name] হিসাবে সংরক্ষণ করা হয়। এই ভেরিয়েবলগুলি সংশ্লিষ্ট রিসোর্স ফোল্ডারে একটি variables.tfvars ফাইল তৈরি করতে ব্যবহৃত হয়। variables.tfvars ফাইলে তাদের মান সহ সমস্ত ভেরিয়েবল রয়েছে। variables.tfvars ফাইলটি একই ফোল্ডারের একটি টেমপ্লেট ফাইল থেকে একটি স্ক্রিপ্ট ব্যবহার করে তৈরি করা হয় ( scripts/setup_terraform_admin_project এ অবস্থিত)।

K8s রেপো ব্যাখ্যা করেছে

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

প্রাথমিক অবকাঠামো নির্মাণের অংশ হিসাবে, k8s_repo তৈরি করা হয়েছে এবং Istio সমস্ত ক্লাস্টারে ইনস্টল করা হয়েছে।

প্রকল্প, GKE ক্লাস্টার, এবং নামস্থান

এই কর্মশালার সংস্থানগুলি বিভিন্ন জিসিপি প্রকল্পে বিভক্ত। প্রকল্পগুলি আপনার কোম্পানির সাংগঠনিক (বা দল) কাঠামোর সাথে মেলে। বিভিন্ন প্রকল্প/পণ্য/সম্পদগুলির জন্য দায়ী দলগুলি (আপনার সংস্থার) বিভিন্ন GCP প্রকল্প ব্যবহার করে। পৃথক প্রকল্প থাকার ফলে আপনি IAM অনুমতিগুলির পৃথক সেট তৈরি করতে এবং একটি প্রকল্প স্তরে বিলিং পরিচালনা করতে পারবেন। উপরন্তু, কোটাও একটি প্রকল্প স্তরে পরিচালিত হয়।

এই কর্মশালায় পাঁচটি দল প্রতিনিধিত্ব করছে, প্রত্যেকের নিজস্ব প্রকল্প রয়েছে।

1. যে পরিকাঠামো দল GCP সংস্থান তৈরি করে তারা Terraform admin project ব্যবহার করে। তারা একটি CSR রেপো (যাকে infrastructure বলা হয়) কোড হিসাবে পরিকাঠামো পরিচালনা করে এবং GCS বালতিতে GCP-তে নির্মিত সংস্থানগুলির সাথে সম্পর্কিত সমস্ত Terraform রাজ্যের তথ্য সংরক্ষণ করে। তারা CSR রেপো এবং Terraform স্টেট GCS বালতি অ্যাক্সেস নিয়ন্ত্রণ করে।
2. শেয়ার্ড ভিপিসি তৈরি করা নেটওয়ার্ক টিম host project ব্যবহার করে। এই প্রকল্পে ভিপিসি, সাবনেট, রুট এবং ফায়ারওয়াল নিয়ম রয়েছে। একটি ভাগ করা VPC থাকার ফলে তারা GCP সংস্থানগুলির জন্য কেন্দ্রীয়ভাবে নেটওয়ার্কিং পরিচালনা করতে পারে। সমস্ত প্রকল্প নেটওয়ার্কিংয়ের জন্য এই একক ভাগ করা ভিপিসি ব্যবহার করেছে।
3. অপস/প্ল্যাটফর্ম দল যারা GKE ক্লাস্টার এবং ASM/Istio কন্ট্রোল প্লেন তৈরি করে তারা ops project ব্যবহার করে। তারা GKE ক্লাস্টার এবং পরিষেবা জালের জীবনচক্র পরিচালনা করে। তারা ক্লাস্টারগুলিকে শক্ত করার জন্য, কুবারনেটস প্ল্যাটফর্মের স্থিতিস্থাপকতা এবং স্কেল পরিচালনা করার জন্য দায়ী। এই কর্মশালায়, আপনি Kubernetes-এ সম্পদ স্থাপনের gitops পদ্ধতি ব্যবহার করেন। অপস প্রকল্পে একটি CSR রেপো (যাকে k8s_repo বলা হয়) বিদ্যমান।
4. সবশেষে, dev1 এবং dev2 টিম (দুটি ডেভেলপমেন্ট টিমের প্রতিনিধিত্ব করে) যারা অ্যাপ্লিকেশন তৈরি করে তাদের নিজস্ব dev1 এবং dev2 projects ব্যবহার করে। এগুলি হল অ্যাপ্লিকেশন এবং পরিষেবা যা আপনি আপনার গ্রাহকদের প্রদান করেন। এগুলি সেই প্ল্যাটফর্মে তৈরি করা হয়েছে যা অপস টিম পরিচালনা করে। রিসোর্সগুলি (ডিপ্লয়মেন্ট, সার্ভিসেস ইত্যাদি) k8s_repo এ পুশ করা হয় এবং উপযুক্ত ক্লাস্টারে স্থাপন করা হয়। এটি লক্ষ করা গুরুত্বপূর্ণ যে এই কর্মশালাটি CI/CD সর্বোত্তম অনুশীলন এবং টুলিংয়ের উপর ফোকাস করে না। আপনি সরাসরি GKE ক্লাস্টারে Kubernetes সংস্থানগুলিকে স্বয়ংক্রিয়ভাবে স্থাপন করতে ক্লাউড বিল্ড ব্যবহার করেন। বাস্তব বিশ্বের উৎপাদন পরিস্থিতিতে, আপনি GKE ক্লাস্টারে অ্যাপ্লিকেশন স্থাপন করতে একটি সঠিক CI/CD সমাধান ব্যবহার করবেন।

এই কর্মশালায় দুই ধরনের GKE ক্লাস্টার রয়েছে।

1. অপস ক্লাস্টার - ডিভোপস টুল চালানোর জন্য অপস টিম ব্যবহার করে। এই কর্মশালায়, তারা পরিষেবা জাল পরিচালনা করতে এএসএম/আইএসটিও নিয়ন্ত্রণ বিমান চালায়।
2. অ্যাপ্লিকেশন (অ্যাপ্লিকেশন) ক্লাস্টার - অ্যাপ্লিকেশনগুলি চালানোর জন্য উন্নয়ন দলগুলি দ্বারা ব্যবহৃত। এই কর্মশালায়, হিপস্টার শপ অ্যাপটি ব্যবহৃত হয়।

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

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

এই ওয়ার্কশপে ব্যবহৃত অ্যাপ্লিকেশন, হিপস্টার শপ অ্যাপ, চারটি অ্যাপ্লিকেশন ক্লাস্টারে মোতায়েন করা হয়েছে। প্রতিটি মাইক্রোসার্ভিস প্রতিটি অ্যাপ্লিকেশন ক্লাস্টারে নিজস্ব নেমস্পেসে বাস করে। হিপস্টার শপ অ্যাপ মোতায়েন (পিওডিএস) ওপিএস ক্লাস্টারে মোতায়েন করা হয় না। তবে, সমস্ত মাইক্রোসার্ভিসের জন্য নেমস্পেস এবং পরিষেবা সংস্থানগুলি ওপিএস ক্লাস্টারেও তৈরি করা হয়। এএসএম/ইস্টিও কন্ট্রোল প্লেন পরিষেবা আবিষ্কারের জন্য কুবারনেটস পরিষেবা রেজিস্ট্রি ব্যবহার করে। পরিষেবার অনুপস্থিতিতে (ওপিএস ক্লাস্টারে), আপনাকে অ্যাপ ক্লাস্টারে চলমান প্রতিটি পরিষেবার জন্য ম্যানুয়ালি সভাপ্ট্রিগুলি তৈরি করতে হবে।

আপনি এই কর্মশালায় একটি 10-স্তরের মাইক্রোসার্ভিসেস অ্যাপ্লিকেশন স্থাপন করেছেন। অ্যাপ্লিকেশনটি একটি ওয়েব-ভিত্তিক ই-বাণিজ্য অ্যাপ্লিকেশন যা " হিপস্টার শপ " নামে পরিচিত যেখানে ব্যবহারকারীরা আইটেমগুলি ব্রাউজ করতে পারে, কার্টে যুক্ত করতে পারে এবং সেগুলি কিনতে পারে।

কুবারনেটস প্রকাশ করে এবং কে 8 এস_প্রেস

আপনি সমস্ত GKE ক্লাস্টারে কুবারনেটস সংস্থান যুক্ত করতে k8s_repo ব্যবহার করেন। আপনি কুবারনেটস প্রকাশ করে এবং k8s_repo প্রতিশ্রুতিবদ্ধ করে এটি করেন। k8s_repo তে সমস্ত প্রতিশ্রুতিবদ্ধ একটি ক্লাউড বিল্ড জব ট্রিগার করে যা কুবারনেটসকে স্থাপন করে সংশ্লিষ্ট ক্লাস্টারে প্রকাশ করে। প্রতিটি ক্লাস্টারের ম্যানিফেস্ট একটি পৃথক ফোল্ডারে অবস্থিত যা ক্লাস্টারের নাম হিসাবে একই।

ছয়টি ক্লাস্টারের নাম হ'ল:

1. GKE-ASM-1-R1-PROD- অঞ্চল 1 এ আঞ্চলিক ওপিএস ক্লাস্টার
2. GKE-ASM-2-R2-PROD- অঞ্চল 2 এ আঞ্চলিক ওপিএস ক্লাস্টার
3. GKE-1-APPS-R1A-PROD- অঞ্চল 1 জোন এ অ্যাপ্লিকেশন ক্লাস্টার
4. GKE-2-APPS-R1B-PROD- অঞ্চল 1 জোনে অ্যাপ্লিকেশন ক্লাস্টার বি
5. GKE-3-APPS-R2A-PROD- অঞ্চল 2 জোন এ অ্যাপ্লিকেশন ক্লাস্টার
6. GKE-4-APPS-R2B-PROD- অঞ্চল 2 জোনে অ্যাপ্লিকেশন ক্লাস্টার বি

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

7. নমুনা অ্যাপ্লিকেশন স্থাপন করুন

উদ্দেশ্য: অ্যাপস ক্লাস্টারে হিপস্টার শপ অ্যাপ্লিকেশন স্থাপন করুন

• ক্লোন k8s-repo
• হিপস্টার শপ অনুলিপি সমস্ত অ্যাপ্লিকেশন ক্লাস্টারে প্রকাশিত
• ওপিএস ক্লাস্টারে হিপস্টার শপ অ্যাপের জন্য পরিষেবা তৈরি করুন
• গ্লোবাল সংযোগ পরীক্ষা করতে অপ্স ক্লাস্টারগুলিতে loadgenerators সেটআপ করুন
• হিপস্টার শপ অ্যাপে সুরক্ষিত সংযোগটি যাচাই করুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

ওপিএস প্রকল্প উত্স রেপো ক্লোন করুন

প্রাথমিক টেরফর্ম অবকাঠামো বিল্ডের অংশ হিসাবে, k8s-repo ইতিমধ্যে ওপিএস প্রকল্পে তৈরি করা হয়েছে।

1. গিট রেপোর জন্য একটি খালি ডিরেক্টরি তৈরি করুন:

mkdir $WORKDIR/k8s-repo
 

2. ইনিশ গিট রেপো, রিমোট যুক্ত করুন এবং রিমোট রেপো থেকে মাস্টারকে টানুন:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. স্থানীয় গিট স্থানীয় কনফিগারেশন সেট করুন।

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

অনুলিপি প্রকাশ, প্রতিশ্রুতিবদ্ধ এবং ধাক্কা

4. হিপস্টার শপ নেমস্পেস এবং পরিষেবাগুলি সমস্ত ক্লাস্টারের জন্য উত্স রেপোতে অনুলিপি করুন।

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. সমস্ত ক্লাস্টারে অ্যাপ্লিকেশন ফোল্ডার কাস্টমাইজেশন.য়ামল অনুলিপি করুন।

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. অ্যাপস ক্লাস্টারগুলির উত্স রেপোতে হিপস্টার শপ ডিপ্লোয়মেন্টস, আরবিএসি এবং পডসিকিউরিটিপলিসি অনুলিপি করুন।

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. কার্টসার্ভিস ডিপ্লোয়মেন্ট, আরবিএসি এবং পডসিকিউরিটিপলিসি একটি ডেভ ক্লাস্টার বাদে সমস্ত থেকে সরান। হিপস্টারশপ মাল্টি-ক্লাস্টার মোতায়েনের জন্য নির্মিত হয়নি, তাই অসঙ্গতিপূর্ণ ফলাফলগুলি এড়াতে আমরা কেবল একটি কার্টসার্ভিস ব্যবহার করছি।

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. কার্টসার্ভিস ডিপ্লোয়মেন্ট, আরবিএসি এবং পডসিকিউরিটিপলিসি কাস্টমাইজেশন.ইমলে কেবল প্রথম দেব ক্লাস্টারে যুক্ত করুন।

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. অপ্স ক্লাস্টার কাস্টমাইজেশন থেকে পোডসিকিউরিটিপোলিসিস, মোতায়েন এবং আরবিএসি ডিরেক্টরিগুলি সরান

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. আরবিএসি প্রকাশে প্রকল্প_আইডি প্রতিস্থাপন করুন।

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. ওপিএস ক্লাস্টারগুলির জন্য উত্স রেপোতে ইনস্রেসগেটওয়ে এবং ভার্চুয়াল সার্ভিস প্রকাশ করে অনুলিপি করুন।

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. প্রতিটি প্রকল্পের একটি ক্লাস্টারে কনফিগার সংযোগকারী সংস্থানগুলি অনুলিপি করুন।

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. কনফিগারেশন সংযোগকারী প্রকাশিত প্রজেক্ট_আইডি প্রতিস্থাপন করুন।

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

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

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. উভয় ওপিএস ক্লাস্টারের জন্য loadgenerator প্রকাশিত ওপিএস প্রজেক্ট আইডি প্রতিস্থাপন করুন।

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. উভয় ওপিএস ক্লাস্টারের জন্য কাস্টমাইজেশন.ইএএমএল -এ loadgenerator সংস্থানগুলি যুক্ত করুন।

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. k8s-repo প্রতিশ্রুতিবদ্ধ।

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

অ্যাপ্লিকেশন স্থাপনা যাচাই করুন

19. কার্ট ব্যতীত সমস্ত অ্যাপ্লিকেশন নেমস্পেসগুলিতে পোডগুলি যাচাই করুন সমস্ত দেব ক্লাস্টারে চলমান অবস্থায় রয়েছে।

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. কার্ট নেমস্পেসে পোডগুলি যাচাই করুন কেবল প্রথম ডেভ ক্লাস্টারে চলমান অবস্থায় রয়েছে।

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

হিপস্টার শপ অ্যাপ অ্যাক্সেস করুন

গ্লোবাল লোড ভারসাম্য

আপনার কাছে এখন চারটি অ্যাপ্লিকেশন ক্লাস্টারে হিপস্টার শপ অ্যাপ মোতায়েন রয়েছে। এই ক্লাস্টারগুলি দুটি অঞ্চল এবং চারটি অঞ্চলে রয়েছে। ক্লায়েন্টরা frontend পরিষেবাটি অ্যাক্সেস করে হিপস্টার শপ অ্যাপটিতে অ্যাক্সেস করতে পারে। frontend পরিষেবাটি চারটি অ্যাপ্লিকেশন ক্লাস্টারে চলে। frontend পরিষেবার চারটি দৃষ্টান্তে ক্লায়েন্ট ট্র্যাফিক পেতে একটি গুগল ক্লাউড লোড ব্যালেন্সার ( জিসিএলবি ) ব্যবহৃত হয়।

ইস্তিও ইনগ্রেস গেটওয়েগুলি কেবল অপ্স ক্লাস্টারে চলে এবং এই অঞ্চলের দুটি জোনাল অ্যাপ্লিকেশন ক্লাস্টারে আঞ্চলিক লোড ব্যালেন্সার হিসাবে কাজ করে। জিসিএলবি গ্লোবাল ফ্রন্টএন্ড সার্ভিসে ব্যাকেন্ড হিসাবে দুটি আইটিও ইনগ্রেস গেটওয়ে (দুটি ওপিএস ক্লাস্টারে চলমান) ব্যবহার করে। আইটিও ইনগ্রেস গেটওয়েগুলি জিসিএলবি থেকে ক্লায়েন্ট ট্র্যাফিক গ্রহণ করে এবং তারপরে ক্লায়েন্টের ট্র্যাফিকটি অ্যাপ্লিকেশন ক্লাস্টারগুলিতে চলমান ফ্রন্টেন্ড পোডগুলিতে প্রেরণ করে।

বিকল্পভাবে, আপনি সরাসরি অ্যাপ্লিকেশন ক্লাস্টারগুলিতে ইস্টিও ইনগ্রেস গেটওয়ে রাখতে পারেন এবং জিসিএলবি সেগুলি ব্যাকেন্ড হিসাবে ব্যবহার করতে পারে।

Gke অটোনেগ কন্ট্রোলার

আইএসটিও ইনগ্রেস গেটওয়ে কুবারনেটস পরিষেবা নেটওয়ার্ক এন্ডপয়েন্ট গ্রুপগুলি (এনইজিএস) ব্যবহার করে জিসিএলবি -র ব্যাকএন্ড হিসাবে নিজেকে নিবন্ধিত করে। নেগস জিসিএলবিএস ব্যবহার করে ধারক-স্থানীয় লোড ব্যালেন্সিংয়ের অনুমতি দেয়। নেগস একটি কুবারনেটস পরিষেবাতে একটি বিশেষ টীকাগুলির মাধ্যমে তৈরি করা হয়, যাতে এটি নিজেকে নেগ কন্ট্রোলারের কাছে নিবন্ধন করতে পারে। অটোনেগ কন্ট্রোলার একটি বিশেষ GKE নিয়ামক যা নেগস তৈরির পাশাপাশি পরিষেবা টীকাগুলি ব্যবহার করে একটি জিসিএলবিতে ব্যাকেন্ড হিসাবে নিয়োগের জন্য স্বয়ংক্রিয় করে তোলে। ইস্টিও কন্ট্রোল প্লেনগুলি আইএসটিও ইনগ্রেস গেটওয়ে সহ প্রাথমিক অবকাঠামো টেরাফর্ম ক্লাউড বিল্ডের সময় মোতায়েন করা হয়। জিসিএলবি এবং অটোনেগ কনফিগারেশন প্রাথমিক টেরফর্ম অবকাঠামো ক্লাউড বিল্ডের অংশ হিসাবে সম্পন্ন হয়।

ক্লাউড এন্ডপয়েন্টগুলি এবং পরিচালিত শংসাপত্রগুলি ব্যবহার করে সুরক্ষিত ইনগ্রেস

জিসিপি পরিচালিত শংসাপত্রগুলি frontend জিসিএলবি পরিষেবাতে ক্লায়েন্ট ট্র্যাফিক সুরক্ষিত করতে ব্যবহৃত হয়। জিসিএলবি গ্লোবাল frontend পরিষেবার জন্য পরিচালিত শংসাপত্র ব্যবহার করে এবং শংসাপত্রটি জিসিএলবিতে সমাপ্ত হয়। এই কর্মশালায়, আপনি পরিচালিত শংসাপত্রের ডোমেন হিসাবে ক্লাউড এন্ডপয়েন্টগুলি ব্যবহার করেন। বিকল্পভাবে, আপনি জিসিপি পরিচালিত শংসাপত্র তৈরি করতে আপনার ডোমেন এবং frontend জন্য একটি ডিএনএস নাম ব্যবহার করতে পারেন।

21. হিপস্টার শপ অ্যাক্সেস করতে, নিম্নলিখিত কমান্ডের লিঙ্ক আউটপুটটিতে ক্লিক করুন।

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. আপনি পরীক্ষা করতে পারেন যে আপনার ক্রোম ট্যাবের URL বারে লক প্রতীকটি ক্লিক করে শংসাপত্রটি বৈধ।

গ্লোবাল লোড ভারসাম্য যাচাই করুন

অ্যাপ্লিকেশন মোতায়েনের অংশ হিসাবে, লোড জেনারেটর উভয় অপ্স ক্লাস্টারে মোতায়েন করা হয়েছিল যা জিসিএলবি হিপস্টার শপ ক্লাউড এন্ডপয়েন্টস লিঙ্কে পরীক্ষার ট্র্যাফিক তৈরি করে। জিসিএলবি ট্র্যাফিক গ্রহণ করছে এবং উভয় ইস্টিও ইনগ্রেস গেটওয়ে প্রেরণ করছে তা যাচাই করুন।

23. ওপিএস প্রকল্পের জন্য জিসিএলবি> মনিটরিং লিঙ্কটি পান যেখানে হিপস্টার শপ জিসিএলবি তৈরি করা হয়।

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. নীচে দেখানো হিসাবে ব্যাকএন্ড ড্রপডাউন মেনু থেকে সমস্ত ব্যাকেন্ড থেকে আইএসটিও-ইনগ্রেসগেটওয়েতে পরিবর্তন করুন।

25. দ্রষ্টব্য ট্র্যাফিক উভয়ই istio-ingressgateways যাচ্ছে।

istio-ingressgateway প্রতি তিনটি নেগ তৈরি করা হয়েছে। যেহেতু ওপিএস ক্লাস্টারগুলি আঞ্চলিক ক্লাস্টার, তাই এই অঞ্চলের প্রতিটি জোনের জন্য একটি নেগ তৈরি করা হয়। istio-ingressgateway পোডগুলি অবশ্য প্রতি অঞ্চলে একক অঞ্চলে চলে। ট্র্যাফিক istio-ingressgateway পোডগুলিতে যেতে দেখানো হয়েছে।

লোড জেনারেটরগুলি উভয় অপ্স ক্লাস্টারে চলছে যে তারা যে দুটি অঞ্চল রয়েছে সেগুলি থেকে ক্লায়েন্ট ট্র্যাফিকের অনুকরণ করে istio-ingressgateway অঞ্চল 2-এ istio-ingressgateway প্রেরণ করা হচ্ছে।

8. স্ট্যাকড্রাইভার সহ পর্যবেক্ষণযোগ্যতা

উদ্দেশ্য: স্ট্যাকড্রাইভার এবং বৈধতা দিয়ে আইএসটিও টেলিমেট্রি সংযুক্ত করুন।

• istio-telemetry রিসোর্স ইনস্টল করুন
• ইস্টিও পরিষেবাদি ড্যাশবোর্ডগুলি তৈরি/আপডেট করুন
• কন্টেইনার লগগুলি দেখুন
• স্ট্যাকড্রাইভারে বিতরণ করা ট্রেসিং দেখুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

ইস্তিওর অন্যতম প্রধান বৈশিষ্ট্য হ'ল অন্তর্নির্মিত পর্যবেক্ষণযোগ্যতা ("o11y")। এর অর্থ হ'ল এমনকি ব্ল্যাক-বক্স, নিরবচ্ছিন্ন পাত্রে, অপারেটররা এখনও গ্রাহকদের পরিষেবা সরবরাহ করে এই পাত্রে প্রবেশ এবং বাইরে যাওয়া ট্র্যাফিক পর্যবেক্ষণ করতে পারে। এই পর্যবেক্ষণটি কয়েকটি ভিন্ন পদ্ধতির আকার নেয়: মেট্রিক, লগ এবং ট্রেস।

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

1. স্ট্যাকড্রাইভার কনফিগার ফাইলটিতে আইটিও ইনস্টল করুন।

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. কে 8 এস-রেপো প্রতিশ্রুতিবদ্ধ।

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. আইটিও → স্ট্যাকড্রাইভার ইন্টিগ্রেশন যাচাই করুন স্ট্যাকড্রাইভার হ্যান্ডলার সিআরডি পান।

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

আউটপুটটি স্ট্যাকড্রাইভার নামের একটি হ্যান্ডলার দেখানো উচিত:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. আইএসটিও মেট্রিকগুলি স্ট্যাকড্রাইভারটিতে রফতানি কাজ করছে তা যাচাই করুন। এই কমান্ড থেকে লিঙ্ক আউটপুট ক্লিক করুন:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

আপনাকে ওপিএস প্রকল্পের নামে নামকরণ করা একটি নতুন ওয়ার্কস্পেস তৈরি করার অনুরোধ জানানো হবে, কেবল ঠিক আছে চয়ন করুন। যদি এটি আপনাকে নতুন ইউআই সম্পর্কে অনুরোধ করে তবে কেবল কথোপকথনটি খারিজ করুন।

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

(আপনি যদি নীচের লাইনগুলি দেখতে চান তবে আপনাকে গন্তব্য_সেবা_নাম লেবেল দ্বারা গোষ্ঠী করতে হবে))

ড্যাশবোর্ডগুলির সাথে মেট্রিকগুলি ভিজ্যুয়ালাইজিং:

এখন যেহেতু আমাদের মেট্রিকগুলি স্ট্যাকড্রাইভার এপিএম সিস্টেমে রয়েছে, আমরা সেগুলি কল্পনা করার একটি উপায় চাই। এই বিভাগে, আমরা একটি প্রাক-বিল্ট ড্যাশবোর্ড ইনস্টল করব যা আমাদের মেট্রিকের চারটি " গোল্ডেন সিগন্যাল " এর মধ্যে তিনটি দেখায়: ট্র্যাফিক (প্রতি সেকেন্ডে অনুরোধ), বিলম্ব (এই ক্ষেত্রে, 99 তম এবং 50 তম পার্সেন্টাইল), এবং ত্রুটিগুলি (আমরা 'এই উদাহরণে স্যাচুরেশন বাদ দিয়ে)।

ইস্তিওর দূত প্রক্সি আমাদের বেশ কয়েকটি মেট্রিক দেয় তবে এগুলি শুরু করার জন্য এটি একটি ভাল সেট। (সম্পূর্ণ তালিকা এখানে )। নোট করুন যে প্রতিটি মেট্রিকের লেবেলগুলির একটি সেট রয়েছে যা ফিল্টারিং, একত্রিতকরণের জন্য ব্যবহার করা যেতে পারে, যেমন: গন্তব্য_সেবা, উত্স_ ওয়ার্কলোড_নামস্পেস, রেসপন্স_কোড, আইএসটিও_টিসিপি_আরসিইভেড_বিটস_টোটাল ইত্যাদি)।

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

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. নতুন যুক্ত "পরিষেবাদি ড্যাশবোর্ড" দেখতে নীচের আউটপুট লিঙ্কে নেভিগেট করুন।

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

আমরা ইউএক্স ব্যবহার করে ড্যাশবোর্ডটি ইন-প্লেস সম্পাদনা করতে পারি, তবে আমাদের ক্ষেত্রে আমরা এপিআই ব্যবহার করে দ্রুত একটি নতুন গ্রাফ যুক্ত করতে যাচ্ছি। এটি করার জন্য, আপনার ড্যাশবোর্ডের সর্বশেষতম সংস্করণটি টানতে হবে, আপনার সম্পাদনাগুলি প্রয়োগ করা উচিত, তারপরে এইচটিটিপি প্যাচ পদ্ধতিটি ব্যবহার করে এটি ব্যাক আপ করুন।

8. আপনি মনিটরিং এপিআই জিজ্ঞাসা করে একটি বিদ্যমান ড্যাশবোর্ড পেতে পারেন। সবেমাত্র যুক্ত হওয়া বিদ্যমান ড্যাশবোর্ডটি পান:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. একটি নতুন গ্রাফ যুক্ত করুন: (50 তম %আইল ল্যাটেন্সি): [ এপিআই রেফারেন্স ] এখন আমরা কোডে আমাদের ড্যাশবোর্ডে একটি নতুন গ্রাফ উইজেট যুক্ত করতে পারি। এই পরিবর্তনটি সহকর্মীদের দ্বারা পর্যালোচনা করা যেতে পারে এবং সংস্করণ নিয়ন্ত্রণে চেক করা যেতে পারে। এখানে যোগ করার জন্য একটি উইজেট রয়েছে যা 50%আইল ল্যাটেন্সি (মিডিয়ান ল্যাটেন্সি) দেখায়।

আপনি যে ড্যাশবোর্ডটি পেয়েছেন তা সম্পাদনা করার চেষ্টা করুন, একটি নতুন স্তবক যুক্ত করুন:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. বিদ্যমান পরিষেবাগুলি ড্যাশবোর্ড আপডেট করুন:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. নিম্নলিখিত আউটপুট লিঙ্কে নেভিগেট করে আপডেট হওয়া ড্যাশবোর্ডটি দেখুন:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. কিছু সাধারণ লগ বিশ্লেষণ করুন।

আইএসটিও সমস্ত ইন-জাল নেটওয়ার্ক ট্র্যাফিকের জন্য কাঠামোগত লগগুলির একটি সেট সরবরাহ করে এবং একটি শক্তিশালী সরঞ্জামে ক্রস-ক্লাস্টার বিশ্লেষণের অনুমতি দেওয়ার জন্য স্ট্যাকড্রাইভার লগিংয়ে এগুলি আপলোড করে। লগগুলি পরিষেবা-স্তরের মেটাডেটা যেমন ক্লাস্টার, ধারক, অ্যাপ্লিকেশন, সংযোগ_আইডি ইত্যাদি দিয়ে টীকাযুক্ত হয়

একটি উদাহরণ লগ এন্ট্রি (এই ক্ষেত্রে, দূত প্রক্সির অ্যাক্সেসলগ) এর মতো দেখতে পারে (ছাঁটাই):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

আপনার লগগুলি এখানে দেখুন:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

আপনি রিসোর্স> কুবারনেটস কনটেইনার নির্বাচন করে এবং "পাইলট" অনুসন্ধান করে ইস্তির নিয়ন্ত্রণ বিমান লগগুলি দেখতে পারেন -

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

ইস্টিওর লগগুলি ছাড়িয়ে আপনি একই ইন্টারফেসে ধারক লগ পাশাপাশি অবকাঠামো বা অন্যান্য জিসিপি পরিষেবাদি লগগুলিও খুঁজে পেতে পারেন। GKE এর জন্য এখানে কয়েকটি নমুনা লগ কোয়েরি রয়েছে। লগস ভিউয়ার আপনাকে লগগুলি থেকে মেট্রিকগুলি তৈরি করতে দেয় (যেমন: "কিছু স্ট্রিংয়ের সাথে মেলে এমন প্রতিটি ত্রুটি গণনা করুন") যা ড্যাশবোর্ডে বা সতর্কতার অংশ হিসাবে ব্যবহার করা যেতে পারে। লগগুলি বিগকোয়ারির মতো অন্যান্য বিশ্লেষণ সরঞ্জামগুলিতেও প্রবাহিত হতে পারে।

হিপস্টার শপের জন্য কিছু নমুনা ফিল্টার:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. বিতরণ ট্রেস দেখুন।

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

টাইমলাইন ভিউ সময়ের সাথে সাথে সমস্ত অনুরোধগুলি দেখায়, তাদের বিলম্বের দ্বারা গ্রাফ করা, বা হিপস্টার স্ট্যাকের মাধ্যমে প্রাথমিক অনুরোধের মধ্যে ব্যয় করা সময়কে শেষ পর্যন্ত শেষ ব্যবহারকারীর প্রতিক্রিয়া জানাতে। বিন্দুগুলির উচ্চতর, ধীর (এবং কম-সুখী!) ব্যবহারকারীর অভিজ্ঞতা।

সেই নির্দিষ্ট অনুরোধটির বিশদ জলপ্রপাতের ভিউ খুঁজতে আপনি একটি বিন্দুতে ক্লিক করতে পারেন। কোনও নির্দিষ্ট অনুরোধের কাঁচা বিবরণ (কেবল সমষ্টিগত পরিসংখ্যান নয়) সন্ধানের এই ক্ষমতাটি পরিষেবাগুলির মধ্যে ইন্টারপ্লে বোঝার জন্য গুরুত্বপূর্ণ, বিশেষত যখন পরিষেবাগুলির মধ্যে বিরল, তবে খারাপ, মিথস্ক্রিয়া শিকার করে।

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

এখানে আপনি আপনার চিহ্নগুলি খুঁজে পেতে পারেন:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

সরঞ্জামটির একটি উদাহরণ স্ক্রিনশট:

9. পারস্পরিক টিএলএস প্রমাণীকরণ

উদ্দেশ্য: মাইক্রোসার্ভেসিস (এটিএনএন) এর মধ্যে সুরক্ষিত সংযোগ।

• জাল প্রশস্ত এমটিএল সক্ষম করুন
• লগগুলি পরিদর্শন করে এমটিএলগুলি যাচাই করুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

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

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

1. ওপিএস ক্লাস্টারগুলিতে মেশপলিসি পরীক্ষা করুন। PERMISSIVE এমটিএলএস এনক্রিপ্ট করা এবং এমটিএলএস উভয়ই ট্র্যাফিকের জন্য অনুমতি দেয়।

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

ইস্টিও আইটিও অপারেটর ব্যবহার করে সমস্ত ক্লাস্টারে কনফিগার করা হয়েছে, যা আইটিওকন্ট্রলপ্লেন কাস্টম রিসোর্স (সিআর) ব্যবহার করে। আমরা আইটিওকন্ট্রলপ্লেন সিআর আপডেট করে এবং কে 8 এস-রেপো আপডেট করে সমস্ত ক্লাস্টারে এমটিএলএস কনফিগার করব। গ্লোবাল> এমটিএলএস> সক্ষম করা: ইস্তিওকন্ট্রলপ্লেন সিআর -এ সত্য: আইটিও নিয়ন্ত্রণ বিমানটিতে নিম্নলিখিত দুটি পরিবর্তনের ফলাফল:

• মেশপলিসি সমস্ত ক্লাস্টারে চলমান সমস্ত পরিষেবার জন্য এমটিএলএস জাল প্রশস্ত চালু করতে চলেছে।
• সমস্ত ক্লাস্টারে চলমান পরিষেবাগুলির মধ্যে ISTIO_MUTUAL ট্র্যাফিকের অনুমতি দেওয়ার জন্য একটি গন্তব্য তৈরি করা হয়।

2. এমটিএলএস ক্লাস্টার প্রশস্ত সক্ষম করতে আমরা আইটিওকন্ট্রলপ্লেন সিআর -তে একটি কাস্টমাইজ প্যাচ প্রয়োগ করব। সমস্ত ক্লাস্টারের জন্য প্রাসঙ্গিক ডিআইআর -তে প্যাচটি অনুলিপি করুন এবং একটি কাস্টমাইজ প্যাচ যুক্ত করুন।

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. কে 8 এস-রেপো প্রতিশ্রুতিবদ্ধ।

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

এমটিএলগুলি যাচাই করুন

5. ওপিএস ক্লাস্টারগুলিতে আরও একবার মেশপলিসি পরীক্ষা করুন। দ্রষ্টব্য এমটিএলএস আর PERMISSIVE নয় এবং কেবল এমটিএলএস ট্র্যাফিকের জন্য অনুমতি দেবে।

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

আউটপুট (অনুলিপি করবেন না):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. আইটিও অপারেটর নিয়ামক দ্বারা নির্মিত গন্তব্য রুল বর্ণনা করুন।

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

আউটপুট (অনুলিপি করবেন না):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

আমরা লগগুলিতে এইচটিটিপি থেকে এইচটিটিপিএসে সরানোও দেখতে পাচ্ছি।

আমরা একটি লগ এন্ট্রি ক্লিক করে এবং তারপরে আপনি যে ক্ষেত্রটি প্রদর্শন করতে চান তার মানটিতে ক্লিক করে আমরা ইউআই -র লগগুলি থেকে এই নির্দিষ্ট ক্ষেত্রটি প্রকাশ করতে পারি, আমাদের ক্ষেত্রে, "প্রোটোকলের পাশের" এইচটিটিপি "এ ক্লিক করুন:

এটি পরিবর্তনটি কল্পনা করার জন্য একটি দুর্দান্ত উপায়ে ফলাফল।:

10. ক্যানারি মোতায়েন

উদ্দেশ্য: ফ্রন্টএন্ড পরিষেবার একটি নতুন সংস্করণ রোলআউট।

• এক অঞ্চলে রোলআউট frontend-v2 (পরবর্তী উত্পাদন সংস্করণ) পরিষেবা
• আস্তে আস্তে ট্র্যাফিককে frontend-v2 এ চালিত করতে DestinationRules ও VirtualServices ব্যবহার করুন
• k8s-repo কমিটের সিরিজ পরিদর্শন করে গিটপস ডিপ্লোয়মেন্ট পাইপলাইন যাচাই করুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

একটি ক্যানারি মোতায়েন একটি নতুন পরিষেবার একটি প্রগতিশীল রোলআউট। একটি ক্যানারি মোতায়েনের মধ্যে, আপনি বর্তমান সংস্করণে অবশিষ্ট শতাংশ প্রেরণ করার সময় নতুন সংস্করণে ক্রমবর্ধমান পরিমাণ ট্র্যাফিক প্রেরণ করেন। একটি সাধারণ প্যাটার্ন হ'ল ট্র্যাফিক বিভাজনের প্রতিটি পর্যায়ে একটি ক্যানারি বিশ্লেষণ সম্পাদন করা এবং একটি বেসলাইনের সাথে নতুন সংস্করণ (বিলম্ব, ত্রুটি হার, স্যাচুরেশন) এর "সোনার সংকেত" তুলনা করা। এটি বিভ্রাট প্রতিরোধে সহায়তা করে এবং ট্র্যাফিক বিভাজনের প্রতিটি পর্যায়ে নতুন "ভি 2" পরিষেবার স্থায়িত্ব নিশ্চিত করে।

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

প্রথমত, আমরা ডিভ 1 অঞ্চলে (ইউএস-ওয়েস্ট 1) ক্যানারি পাইপলাইনটি চালাব এবং সেই অঞ্চলের উভয় ক্লাস্টারে ফ্রন্টেন্ড ভি 2 রোল আউট করব। দ্বিতীয়ত, আমরা দেব 2 অঞ্চলে (মার্কিন-কেন্দ্রিক) ক্যানারি পাইপলাইন চালাব এবং সেই অঞ্চলের উভয় ক্লাস্টারে ভি 2 স্থাপন করব। সমস্ত অঞ্চল জুড়ে সমান্তরালভাবে বনাম, ক্রমে অঞ্চলগুলিতে পাইপলাইন চালানো, খারাপ কনফিগারেশন দ্বারা সৃষ্ট বৈশ্বিক বিভ্রাট বা ভি 2 অ্যাপ্লিকেশনটিতে বাগ দ্বারা এড়াতে সহায়তা করে।

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

1. ক্লাউড শেল থেকে, বাকী কমান্ডগুলি চালানো সহজ করার জন্য কিছু এনভ ভেরিয়েবলগুলি সংজ্ঞায়িত করুন।

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. বেসলাইনটি কে 8 এস-রেপোতে অনুলিপি করতে রেপো_সেটআপ.এসএইচ স্ক্রিপ্টটি চালান।

$CANARY_DIR/repo-setup.sh 
 

নিম্নলিখিত প্রকাশগুলি অনুলিপি করা হয়:

• ফ্রন্টএন্ড-ভি 2 মোতায়েন
• ফ্রন্টএন্ড-ভি 1 প্যাচ ("ভি 1" লেবেল এবং একটি "/সংস্করণ" শেষ পয়েন্ট সহ একটি চিত্র অন্তর্ভুক্ত করতে)
• শ্বাসকষ্ট , একটি ছোট পোড যা এইচটিটিপি প্রতিক্রিয়া বিতরণ মুদ্রণ করবে এবং আমাদের রিয়েল টাইমে ক্যানারি মোতায়েনের কল্পনা করতে সহায়তা করবে।
• ফ্রন্টএন্ড আইটিও গন্তব্যস্থল - "সংস্করণ" ডিপ্লোয়মেন্ট লেবেলের উপর ভিত্তি করে ফ্রন্টেন্ড কুবারনেটস পরিষেবাটি দুটি সাবসেট, ভি 1 এবং ভি 2 এ বিভক্ত করে
• ফ্রন্টএন্ড আইটিও ভার্চুয়াল সার্ভিস - ট্র্যাফিকের 100% রুটগুলি ফ্রন্টেন্ড ভি 1 এ। এটি কুবারনেটস পরিষেবা ডিফল্ট রাউন্ড-রবিন আচরণকে ওভাররাইড করে, যা অবিলম্বে সমস্ত DEV1 আঞ্চলিক ট্র্যাফিকের 50% ফ্রন্টেন্ড ভি 2 এ প্রেরণ করবে।

3. K8S_repo এ পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. ওপিএস 1 প্রকল্পের জন্য কনসোলে ক্লাউড বিল্ডে নেভিগেট করুন। ক্লাউড বিল্ড পাইপলাইনটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করুন , তারপরে উভয় ডিভ 1 ক্লাস্টারে ফ্রন্টেন্ড নেমস্পেসে পোড পান। আপনি নিম্নলিখিত দেখতে হবে:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

দ্রষ্টব্য: সিটিআরএল-সি ওয়াচ কমান্ডগুলি থেকে প্রস্থান করতে

আমরা আমাদের ক্লাউডশেল উইন্ডোটি 2 প্যানে বিভক্ত করতে টিএমএক্স ব্যবহার করব:

• নীচের ফলকটি ফ্রন্টএন্ড পরিষেবার জন্য এইচটিটিপি প্রতিক্রিয়া বিতরণ পর্যবেক্ষণ করতে ওয়াচ কমান্ডটি চালাবে।
• শীর্ষ ফলকটি আসল ক্যানারি পাইপলাইন স্ক্রিপ্টটি চালাবে।

6. ক্লাউড শেল উইন্ডোটি বিভক্ত করতে এবং নীচের ফলকে ওয়াচ কমান্ডটি কার্যকর করতে কমান্ডটি চালান।

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

আউটপুট (অনুলিপি করবেন না)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

আমরা দেখতে পাচ্ছি যে সমস্ত ট্র্যাফিক নতুন ভার্চুয়াল সার্ভিসে সংজ্ঞায়িত ফ্রন্টেন্ড ভি 1 মোতায়েনের দিকে যাচ্ছে।

7. ডিভ 1 অঞ্চলে ক্যানারি পাইপলাইন কার্যকর করুন। আমরা এমন একটি স্ক্রিপ্ট সরবরাহ করি যা ভার্চুয়াল সার্ভিসে ফ্রন্টেন্ড-ভি 2 ট্র্যাফিক শতাংশকে আপডেট করে (ওজন 20%, 50%, 80%, তারপরে 100%) আপডেট করে। আপডেটের মধ্যে, স্ক্রিপ্টটি ক্লাউড বিল্ড পাইপলাইনটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে। ডিভ 1 অঞ্চলের জন্য ক্যানারি ডিপ্লোয়মেন্ট স্ক্রিপ্টটি চালান। দ্রষ্টব্য - এই স্ক্রিপ্টটি সম্পূর্ণ হতে প্রায় 10 মিনিট সময় নেয়।

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

আপনি নীচের উইন্ডোতে রিয়েল টাইমে ট্র্যাফিক বিভাজন দেখতে পাচ্ছেন যেখানে আপনি উত্তর কমান্ডটি চালাচ্ছেন। উদাহরণস্বরূপ, 20% চিহ্নে:

আউটপুট (অনুলিপি করবেন না)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. ফ্রন্টএন্ড-ভি 2 এর জন্য ডিভ 2 রোলআউট শেষ হয়ে গেলে আপনার স্ক্রিপ্টের শেষে একটি সাফল্যের বার্তা দেখতে হবে:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. এবং একটি ডেভ 2 পোড থেকে সমস্ত ফ্রন্টেন্ড ট্র্যাফিক ফ্রন্টএন্ড-ভি 2 এ যাওয়া উচিত:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. বিভক্ত ফলকটি বন্ধ করুন।

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. উত্পন্ন লিঙ্কে ক্লাউড উত্স রেপোতে নেভিগেট করুন।

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

তালিকার শীর্ষে সাম্প্রতিক প্রতিশ্রুতিবদ্ধ সহ প্রতিটি ট্র্যাফিক শতাংশের জন্য আপনার আলাদা কমিট দেখতে হবে:

এখন, আপনি ডিভ 2 অঞ্চলের জন্য একই প্রক্রিয়াটি পুনরাবৃত্তি করবেন। নোট করুন যে ডিইভি 2 অঞ্চলটি এখনও ভি 1 তে "লক" রয়েছে। এটি কারণ বেসলাইন রেপো_সেটআপ স্ক্রিপ্টে, আমরা একটি ভার্চুয়াল সার্ভিসকে স্পষ্টভাবে সমস্ত ট্র্যাফিক ভি 1 এ প্রেরণে ঠেলে দিয়েছি। এইভাবে, আমরা ডিইভি 1 এ নিরাপদে একটি আঞ্চলিক ক্যানারি করতে সক্ষম হয়েছি এবং বিশ্বব্যাপী নতুন সংস্করণটি বের করার আগে এটি সফলভাবে চলতে নিশ্চিত করেছিলাম।

12. ক্লাউড শেল উইন্ডোটি বিভক্ত করতে এবং নীচের ফলকে ওয়াচ কমান্ডটি কার্যকর করতে কমান্ডটি চালান।

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

আউটপুট (অনুলিপি করবেন না)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

আমরা দেখতে পাচ্ছি যে সমস্ত ট্র্যাফিক নতুন ভার্চুয়াল সার্ভিসে সংজ্ঞায়িত ফ্রন্টেন্ড ভি 1 মোতায়েনের দিকে যাচ্ছে।

13. DEV2 অঞ্চলে ক্যানারি পাইপলাইন কার্যকর করুন। আমরা এমন একটি স্ক্রিপ্ট সরবরাহ করি যা ভার্চুয়াল সার্ভিসে ফ্রন্টেন্ড-ভি 2 ট্র্যাফিক শতাংশকে আপডেট করে (ওজন 20%, 50%, 80%, তারপরে 100%) আপডেট করে। আপডেটের মধ্যে, স্ক্রিপ্টটি ক্লাউড বিল্ড পাইপলাইনটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করে। ডিভ 1 অঞ্চলের জন্য ক্যানারি ডিপ্লোয়মেন্ট স্ক্রিপ্টটি চালান। দ্রষ্টব্য - এই স্ক্রিপ্টটি সম্পূর্ণ হতে প্রায় 10 মিনিট সময় নেয়।

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

আউটপুট (অনুলিপি করবেন না)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. ডিইভি 2 -তে উত্তরোত্তর পোড থেকে, ডিইভি 2 পোডগুলি থেকে ট্র্যাফিক দেখুন ফ্রন্টেন্ড ভি 1 থেকে ভি 2 এ ক্রমান্বয়ে সরানো। স্ক্রিপ্টটি শেষ হয়ে গেলে আপনার দেখা উচিত:

আউটপুট (অনুলিপি করবেন না)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. বিভক্ত ফলকটি বন্ধ করুন।

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

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

১১. অনুমোদনের নীতি

উদ্দেশ্য: মাইক্রোসার্ভেসিস (এথজেড) এর মধ্যে আরবিএসি সেট আপ করুন।

• কোনও মাইক্রোসার্ভিসে অ্যাক্সেস অস্বীকার করার জন্য AuthorizationPolicy তৈরি করুন
• মাইক্রোসার্ভিসে নির্দিষ্ট অ্যাক্সেসের অনুমতি দেওয়ার জন্য AuthorizationPolicy তৈরি করুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

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

আইটিও নীতিগুলি প্রমাণীকরণ এবং অনুমোদন উভয়ই কভার করে। প্রমাণীকরণ পরিচয় যাচাই করে (এই সার্ভারটি কি তারা বলে যে তারা বলে?), এবং অনুমোদনের অনুমতিগুলি যাচাই করে (এই ক্লায়েন্টটি কি এটি করার অনুমতি দেয়?)। আমরা মডিউল 1 (মেশপলিসি) এর মিউচুয়াল টিএলএস বিভাগে আইটিও প্রমাণীকরণটি কভার করেছি। এই বিভাগে, আমরা আমাদের অ্যাপ্লিকেশন কাজের চাপ, মুদ্রার সার্ভিসে অ্যাক্সেস নিয়ন্ত্রণ করতে কীভাবে আইএসটিও অনুমোদনের নীতিগুলি ব্যবহার করতে শিখব।

প্রথমত, আমরা সমস্ত 4 টি ডেভ ক্লাস্টার জুড়ে একটি অনুমোদনের পলি স্থাপন করব, মুদ্রার সার্ভিসে সমস্ত অ্যাক্সেস বন্ধ করব এবং ফ্রন্টেন্ডে একটি ত্রুটি ট্রিগার করব। তারপরে, আমরা কেবল ফ্রন্টএন্ড পরিষেবাটিকে মুদ্রার সার্ভিসে অ্যাক্সেসের অনুমতি দেব।

1. currency-deny-all.yaml এর বিষয়বস্তুগুলি পরিদর্শন করুন। এই নীতিটি মুদ্রার সার্ভিসে অ্যাক্সেসকে সীমাবদ্ধ করতে ডিপ্লোয়মেন্ট লেবেল নির্বাচকদের ব্যবহার করে। কীভাবে কোনও spec ক্ষেত্র নেই তা লক্ষ্য করুন - এর অর্থ এই নীতিটি নির্বাচিত পরিষেবাতে সমস্ত অ্যাক্সেস অস্বীকার করবে ।

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

আউটপুট (অনুলিপি করবেন না)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. উভয় অঞ্চলে ওপিএস ক্লাস্টারগুলির জন্য মুদ্রা নীতিটি কে 8 এস-রেপোতে অনুলিপি করুন।

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. পরিবর্তনগুলি ধাক্কা।

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি পরীক্ষা করুন:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

5. বিল্ডটি সফলভাবে শেষ হওয়ার পরে, নিম্নলিখিত লিঙ্কটিতে একটি ব্রাউজারে হিপস্টারশপ ফ্রন্টেন্ডে পৌঁছানোর চেষ্টা করুন:

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

আপনার মুদ্রার সার্ভিস থেকে একটি অনুমোদনের ত্রুটি দেখতে হবে:

6. আসুন অনুসন্ধান করুন যে কীভাবে মুদ্রা পরিষেবা এই অনুমোদনের পলি প্রয়োগ করছে। প্রথমত, মুদ্রা পোডগুলির একটির জন্য দূত প্রক্সিতে ট্রেস-স্তরের লগগুলি সক্ষম করুন, যেহেতু অবরুদ্ধ অনুমোদনের কলগুলি ডিফল্টরূপে লগ করা হয় না।

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. মুদ্রা পরিষেবার সিডিকার প্রক্সি থেকে আরবিএসি (অনুমোদন) লগগুলি পান। আপনার একটি "প্রয়োগ করা অস্বীকার করা" বার্তাটি দেখতে হবে, এটি নির্দেশ করে যে মুদ্রাগুলি সমস্ত অভ্যন্তরীণ অনুরোধগুলি ব্লক করতে সেট করা আছে।

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

আউটপুট (অনুলিপি করবেন না)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. এখন, আসুন সামনের অংশটি - তবে অন্যান্য ব্যাকএন্ড পরিষেবাগুলি নয় - মুদ্রার সার্ভিস অ্যাক্সেস করার অনুমতি দিন । currency-allow-frontend.yaml খুলুন এবং এর বিষয়বস্তুগুলি পরিদর্শন করুন। নোট করুন যে আমরা নিম্নলিখিত নিয়ম যুক্ত করেছি:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

আউটপুট (অনুলিপি করবেন না)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

এখানে, আমরা মুদ্রা পরিষেবা অ্যাক্সেসের জন্য একটি নির্দিষ্ট উত্স.প্রিনিপাল (ক্লায়েন্ট) হোয়াইটলিস্টিং করছি। এই উত্স.প্রিনিপাল আইএস কুবারনেটস পরিষেবা অ্যাকাউন্ট দ্বারা সংজ্ঞায়িত করা হয়। এই ক্ষেত্রে, আমরা যে পরিষেবা অ্যাকাউন্টটি সাদা করি তা হ'ল ফ্রন্টেন্ড নেমস্পেসে ফ্রন্টএন্ড সার্ভিস অ্যাকাউন্ট।

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

9. আপডেট হওয়া মুদ্রা নীতিটি অনুলিপি করুন

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. পরিবর্তনগুলি ধাক্কা।

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. বিল্ড সফলভাবে শেষ হওয়ার পরে, আবার হিপস্টারশপ ফ্রন্টেন্ডটি খুলুন। এবার আপনার হোমপেজে কোনও ত্রুটি দেখা উচিত নয় - এটি হ'ল কারণটি বর্তমান পরিষেবাটি অ্যাক্সেস করার জন্য স্পষ্টভাবে অনুমতি দেওয়া হয়েছে।
13. এখন, আপনার কার্টে আইটেম যুক্ত করে এবং "প্লেস অর্ডার" ক্লিক করে একটি চেকআউট কার্যকর করার চেষ্টা করুন। এবার, আপনার মুদ্রা পরিষেবা থেকে একটি মূল্য -রূপান্তর ত্রুটি দেখতে হবে - এটি কারণ আমরা কেবল সামনের অংশটি সাদা করে রেখেছি, সুতরাং চেকআউটস সার্ভিস এখনও মুদ্রার সার্ভিস অ্যাক্সেস করতে অক্ষম।

14. শেষ অবধি, আসুন আমাদের মুদ্রার সার্ভিস অনুমোদনের পলিগুলিতে আরও একটি নিয়ম যুক্ত করে মুদ্রায় চেকআউট পরিষেবা অ্যাক্সেসের অনুমতি দিন । নোট করুন যে আমরা কেবলমাত্র দুটি পরিষেবায় মুদ্রা অ্যাক্সেস খুলছি যা এটি অ্যাক্সেস করতে হবে - ফ্রন্টেন্ড এবং চেকআউট। অন্যান্য ব্যাকেন্ডগুলি এখনও অবরুদ্ধ করা হবে।
15. currency-allow-frontend-checkout.yaml খুলুন এবং এর বিষয়বস্তুগুলি পরিদর্শন করুন। লক্ষ্য করুন যে নিয়মের তালিকাটি যৌক্তিক বা - মুদ্রা হিসাবে কাজ করে কেবল এই দুটি পরিষেবা অ্যাকাউন্টের কোনওটির সাথে কেবলমাত্র কাজের চাপ থেকে অনুরোধগুলি গ্রহণ করবে।

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

আউটপুট (অনুলিপি করবেন না)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. চূড়ান্ত অনুমোদনের নীতিটি কে 8 এস-রেপোতে অনুলিপি করুন।

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. ধাক্কা পরিবর্তন

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. পূর্বে খোলা ট্যাবে বা নিম্নলিখিত লিঙ্কটিতে ক্লিক করে ওপিএস প্রকল্প ক্লাউড বিল্ডের স্থিতি দেখুন:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. বিল্ড সফলভাবে শেষ হওয়ার পরে, একটি চেকআউট কার্যকর করার চেষ্টা করুন - এটি সফলভাবে কাজ করা উচিত।

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

12. অবকাঠামো স্কেলিং

উদ্দেশ্য: নতুন অঞ্চল, প্রকল্প এবং ক্লাস্টার যুক্ত করে স্কেল অবকাঠামো।

• infrastructure রেপো ক্লোন
• নতুন সংস্থান তৈরি করতে টেরাফর্ম ফাইলগুলি আপডেট করুন
• নতুন অঞ্চলে 2 টি সাবনেট (ওপিএস প্রকল্পের জন্য একটি এবং নতুন প্রকল্পের জন্য একটি)
• নতুন অঞ্চলে নতুন ওপিএস ক্লাস্টার (নতুন সাবনেটে)
• নতুন অঞ্চলের জন্য নতুন আইটিও নিয়ন্ত্রণ বিমান
• নতুন অঞ্চলে নতুন প্রকল্পে 2 টি অ্যাপ্লিকেশন ক্লাস্টার
• infrastructure রেপোতে প্রতিশ্রুতিবদ্ধ
• ইনস্টলেশন যাচাই করুন

দ্রুত ট্র্যাক স্ক্রিপ্ট

আপনি যদি এই পদ্ধতিটি চয়ন করেন তবে এই ল্যাবটি সম্পূর্ণ করতে নিম্নলিখিত স্ক্রিপ্টটি চালান।

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

অনুলিপি এবং পেস্ট পদ্ধতি ল্যাব নির্দেশাবলী

আপনি যদি ইতিমধ্যে এই ল্যাবটির জন্য দ্রুত ট্র্যাক স্ক্রিপ্টটি সম্পন্ন করে থাকেন তবে নীচে অনুলিপি এবং পেস্ট পদ্ধতিটি সম্পাদন করবেন না ** ** **

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

The current platform consists of two regions and clusters in two zones per region. You can think of scaling the platform in two ways:

• Vertically - within each region by adding more compute. This is done either by adding more nodes (or node pools) to existing clusters or by adding new clusters within the region. This is done via the infrastructure repo. The simplest path is adding nodes to existing clusters. No additional configuration is required. Adding new clusters may require additional subnets (and secondary ranges), adding appropriate firewall rules, adding the new clusters to the regional ASM/Istio service mesh control plane and deploying application resources to the new clusters.
• Horizontally - by adding more regions. The current platform gives you a regional template. It consists on a regional ops cluster where the ASM/Istio control please resides and two (or more) zonal application clusters where application resources are deployed.

In this workshop, you scale the platform "horizontally" as it encompasses the vertical use case steps as well. In order to horizontally, scale the platform by adding a new region (r3) to the platform, the following resources need to be added:

1. Subnets in the host project shared VPC in region r3 for the new ops and application clusters.
2. A regional ops cluster in region r3 where the ASM/Istio control plane resides.
3. Two zonal application clusters in two zones on region r3.
4. Update to the k8s-repo:
5. Deploy ASM/Istio control plane resources to the ops cluster in region r3.
6. Deploy ASM/Istio shared control plane resources to the app clusters in region r3.
7. While you don't need to create a new project, the steps in the workshop demonstrate adding a new project dev3 to cover the use case of adding a new team to the platform.

Infrastructure repo is used to add new resources stated above.

1. In Cloud Shell, navigate to WORKDIR and clone the infrastructure repo.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. Clone the workshop source repo add-proj branch into the add-proj-repo directory.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. Copy files from the add-proj branch in the source workshop repo. The add-proj branch contains the changes for this section.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. Replace the infrastructure directory in the add-proj repo directory with a symlink to the infra-repo directory to allow the scripts on the branch to run.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. Run the add-project.sh script to copy the shared states and vars to the new project directory structure.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. Commit and push changes to create new project

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. The commit triggers the infrastructure repo to deploy the infrastructure with the new resources. View the Cloud Build progress by clicking on the output of the following link and navigating to the latest build at the top.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

This step takes 25 - 30 minutes to complete. Good time for a coffee break.

The last step of the infrastructure Cloud Build creates new Kubernetes resources in the k8s-repo . This triggers the Cloud Build in the k8s-repo (in the ops project). The new Kubernetes resources are for the three new clusters added in the previous step. ASM/Istio control plane and shared control plane resources are added to the new clusters with the k8s-repo Cloud Build.

8. After the infrastructure Cloud Build successfully finishes, navigate to the k8s-repo latest Cloud Build run by clicking on the following output link.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. Run the following script to add the new clusters to the vars and kubeconfig file.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. Change the KUBECONFIG variable to point to the new kubeconfig file.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. List your cluster contexts. You should see eight clusters.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Verify Istio Installation

12. Ensure Istio is installed on the new ops cluster by checking all pods are running and jobs have completed.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. Ensure Istio is installed on both dev3 clusters. Only Citadel, sidecar-injector and coredns run in the dev3 clusters. They share an Istio controlplane running in the ops-3 cluster.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Verify service discovery for shared control planes

14. Verify the secrets are deployed in all ops clusters for all six application clusters.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. Circuit Breaking

Objective: Implement a Circuit Breaker for the shipping Service.

• Create a DestinationRule for the shipping Service to implement a circuit breaker
• Use fortio (a load gen utility) to validate circuit breaker for the shipping Service by force tripping the circuit

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Now that we've learned some basic monitoring and troubleshooting strategies for Istio-enabled services, let's look at how Istio helps you improve the resilience of your services, reducing the amount of troubleshooting you'll have to do in the first place.

A microservices architecture introduces the risk of cascading failures , where the failure of one service can propagate to its dependencies, and the dependencies of those dependencies, causing a "ripple effect" outage that can potentially affect end-users. Istio provides a Circuit Breaker traffic policy to help you isolate services, protecting downstream (client-side) services from waiting on failing services, and protecting upstream (server-side) services from a sudden flood of downstream traffic when they do come back online. Overall, using Circuit Breakers can help you avoid all your services failing their SLOs because of one backend service that is hanging.

The Circuit Breaker pattern is named for an electrical switch that can "trip" when too much electricity flows through, protecting devices from overload. In an Istio setup , this means that Envoy is the circuit breaker, keeping track of the number of pending requests for a service. In this default closed state, requests flow through Envoy uninterrupted.

But when the number of pending requests exceeds your defined threshold, the circuit breaker trips (opens), and Envoy immediately returns an error. This allows the server to fail fast for the client, and prevents the server application code from receiving the client's request when overloaded.

Then, after your defined timeout, Envoy moves to a half open state, where the server can start receiving requests again in a probationary way, and if it can successfully respond to requests, the circuit breaker closes again, and requests to the server begin to আবার প্রবাহ

This diagram summarizes the Istio circuit breaker pattern. The blue rectangles represent Envoy, the blue-filled circle represents the client, and the white-filled circles represent the server container:

You can define Circuit Breaker policies using Istio DestinationRules. In this section, we'll apply the following policy to enforce a circuit breaker for the shipping service:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

There are two DestinationRule fields to note here. connectionPool defines the number of connections this service will allow. The outlierDetection field is where we configure how Envoy will determine the threshold at which to open the circuit breaker. Here, every second (interval), Envoy will count the number of errors it received from the server container. If it exceeds the consecutiveErrors threshold, the Envoy circuit breaker will open, and 100% of productcatalog pods will be shielded from new client requests for 10 seconds. Once the Envoy circuit breaker is open (ie. active), clients will receive 503 (Service Unavailable) errors. এর কর্ম এই দেখুন.

1. Set environment variables for the k8s-repo and asm dir to simplify commands.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. Update the k8s-repo

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. Update the shipping service DestinationRule on both Ops clusters.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Copy a Fortio load generator pod into the GKE_1 cluster in the Dev1 region. This is the client pod we'll use to "trip" the circuit breaker for shippingservice.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. পরিবর্তনের প্রতিশ্রুতি দিন।

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Wait for Cloud Build to complete.
7. Back in Cloud Shell, use the fortio pod to send gRPC traffic to shippingservice with 1 concurrent connection, 1000 requests total - this will not trip the circuit breaker, because we have not exceeded the connectionPool settings yet.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (do not copy)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. Now run fortio again, increasing the number of concurrent connections to 2, but keeping the total number of requests constant. We should see up to two-thirds of the requests return an "overflow" error, because the circuit breaker has been tripped: in the policy we defined, only 1 concurrent connection is allowed in a 1-second interval.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (do not copy)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy keeps track of the number of connections it dropped when the circuit breaker is active, with the upstream_rq_pending_overflow metric. Let's find this in the fortio pod:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

Output (do not copy)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. Clean up by removing the circuit breaker policy from both regions.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

This section demonstrated how to set up a single circuit breaker policy for a service. A best practice is to set up a circuit breaker for any upstream (backend) service that has the potential to hang. By applying Istio circuit breaker policies, you help isolate your microservices, build fault tolerance into your architecture, and reduce the risk of cascading failures under high load.

14. Fault Injection

Objective: Test the resilience of the recommendation Service by introducing delays (before it is pushed to production).

• Create a VirtualService for the recommendation Service to introduce a 5s delay
• Test the delay using fortio load generator
• Remove the delay in the VirtualService and validate

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Adding circuit breaker policies to your services is one way to build resilience against services in production. But circuit breaking results in faults — potentially user-facing errors — which is not ideal. To get ahead of these error cases, and better predict how your downstream services might respond when backends do return errors, you can adopt chaos testing in a staging environment. Chaos testing is the practice of deliberately breaking your services, in order to analyze weak points in the system and improve fault tolerance. You can also use chaos testing to identify ways to mitigate user-facing errors when backends fail - for instance, by displaying a cached result in a frontend.

Using Istio for fault injection is helpful because you can use your production release images, and add the fault at the network layer, instead of modifying source code. In production, you might use a full-fledged chaos testing tool to test resilience at the Kubernetes/compute layer in addition to the network layer.

You can use Istio for chaos testing by applying a VirtualService with the "fault" field. Istio supports two kinds of faults: delay faults (inject a timeout) and abort faults (inject HTTP errors). In this example, we'll inject a 5-second delay fault into the recommendations service . But this time instead of using a circuit breaker to "fail fast" against this hanging service, we will force downstream services to endure the full timeout.

11. Navigate into the fault injection directory.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. Open k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml to inspect its contents. Notice that Istio has an option to inject the fault into a percentage of the requests - here, we'll introduce a timeout into all recommendationservice requests.

Output (do not copy)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. Copy the VirtualService into k8s_repo. We'll inject the fault globally, across both regions.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. ধাক্কা পরিবর্তন

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Wait for Cloud Build to complete.
16. Exec into the fortio pod deployed in the circuit breaker section, and send some traffic to recommendationservice.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

Output (do not copy)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. Another way to see the fault we injected in action is open the frontend in a web browser, and click on any product. A product page should take 5 extra seconds to load, since it fetches the recommendations that are displayed at the bottom of the page.
18. Clean up by removing the fault injection service from both Ops clusters.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. Push changes:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. Monitoring the Istio Control Plane

ASM installs four important control plane components: Pilot, Mixer, Galley and Citadel. Each sends its relevant monitoring metrics to Prometheus, and ASM ships with Grafana dashboards that let operators visualize this monitoring data and assess the health and performance of the control plane.

Viewing the Dashboards

20. Port-forward your Grafana service installed with Istio

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Open Grafana in your browser
22. Click on the "Web Preview" icon on the top right corner of your Cloud Shell Window
23. Click Preview on port 3000 (Note: if the port is not 3000, click on change port and select port 3000)
24. This will open a tab in your browser with a URL similar to " BASE_URL/?orgId=1&authuser=0&environment_id=default "
25. View available dashboards
26. Modify the URL to " BASE_URL/dashboard "
27. Click on "istio" folder to view available dashboards
28. Click on any of those dashboards to view the performance of that component. We'll look at the important metrics for each component in the following sections.

Monitoring Pilot

Pilot is the control plane component that distributes networking and policy configuration to the data plane (the Envoy proxies). Pilot tends to scale with the number of workloads and deployments, although not necessarily with the amount of traffic to those workloads. An unhealthy Pilot can:

• consume more resources than necessary (CPU and/or RAM)
• result in delays in pushing updated configuration information to Envoys

Note: if Pilot is down, or if there are delays, your workloads still serve traffic.

23. Navigate to " BASE_URL/dashboard/db/istio-pilot-dashboard " in your browser to view Pilot metrics.

Important monitored metrics

সম্পদ ব্যবহার

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Pilot Push Information

This section monitors Pilots pushes of configuration to your Envoy proxies.

• Pilot Pushes shows the type of configuration pushed at any given time.
• ADS Monitoring shows the number of Virtual Services, Services and Connected Endpoints in the system.
• Clusters with no known endpoints shows endpoints that have been configured but do not have any instances running (which may indicate external services, such as *.googleapis.com).
• Pilot Errors show the number of errors encountered over time.
• Conflicts show the number of conflicts which are ambiguous configuration on listeners.

If you have Errors or Conflicts, you have bad or inconsistent configuration for one or more of your services. See Troubleshooting the data plane for information.

Envoy Information

This section contains information about the Envoy proxies contacting the control plane. Contact GCP support if you see repeated XDS Connection Failures.

Monitoring Mixer

Mixer is the component that funnels telemetry from the Envoy proxies to telemetry backends (typically Prometheus, Stackdriver, etc). In this capacity, it is not in the data plane. It is deployed as two Kubernetes Jobs (called Mixer) deployed with two different service names (istio-telemetry and istio-policy).

Mixer can also be used to integrate with policy systems. In this capacity, Mixer does affect the data plane, as policy checks to Mixer that fail block access to your services.

Mixer tends to scale with volume of traffic.

24. Navigate to " BASE_URL/dashboard/db/istio-mixer-dashboard " in your browser to view Mixer metrics.

Important monitored metrics

সম্পদ ব্যবহার

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Mixer Overview

• Response Duration is an important metric. While reports to Mixer telemetry are not in the datapath, if these latencies are high it will definitely slow down sidecar proxy performance. You should expect the 90th percentile to be in the single-digit milliseconds, and the 99th percentile to be under 100ms.

• Adapter Dispatch Duration indicates the latency Mixer is experiencing in calling adapters (through which it sends information to telemetry and logging systems). High latencies here will absolutely affect performance on the mesh. Again, p90 latencies should be under 10ms.

Monitoring Galley

Galley হল Istio এর কনফিগারেশন বৈধতা, ইনজেশন, প্রসেসিং এবং ডিস্ট্রিবিউশন কম্পোনেন্ট। It conveys configuration from the Kubernetes API server to Pilot. Like Pilot, it tends to scale with the number of services and endpoints in the system.

25. Navigate to " BASE_URL/dashboard/db/istio-galley-dashboard " in your browser to view Galley metrics.

Important monitored metrics

Resource Validation

The most important metric to follow which indicates the number of resources of various types like Destination rules, Gateways and Service entries that are passing or failing validation.

সংযুক্ত ক্লায়েন্ট

Indicates how many clients are connected to Galley; typically this will be 3 (pilot, istio-telemetry, istio-policy) and will scale as those components scale.

16. Troubleshooting Istio

Troubleshooting the data plane

If your Pilot dashboard indicates that you have configuration issues, you should examine PIlot logs or use istioctl to find configuration problems.

To examine Pilot logs, run kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery, replacing istio-pilot-... with the pod identifier for the Pilot instance you want to troubleshoot.

In the resulting log, search for a Push Status message. যেমন:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

The Push Status will indicate any issues that occurred when trying to push the configuration to Envoy proxies – in this case, we see several "Duplicate cluster" messages, which indicate duplicate upstream destinations.

For assistance in diagnosing problems, contact Google Cloud support with issues.

Finding configuration errors

In order to use istioctl to analyze your configuration, run istioctl experimental analyze -k --context $OPS_GKE_1 . This will perform an analysis of configuration in your system, indicate any problems along with any suggested changes. See documentation for a full list of configuration errors that this command can detect.

17. Cleanup

The following steps are performed by an administrator after the workshop is completed.

An administrator runs the cleanup_workshop.sh script to delete resources created by the bootstrap_workshop.sh script. You need the following pieces of information for the cleanup script to run.

• Organization name - for example yourcompany.com
• Workshop ID - in the form YYMMDD-NN for example 200131-01
• Admin GCS bucket - defined in the bootstrap script.

13. Open Cloud Shell, perform all actions below in Cloud Shell. নীচের লিঙ্কে ক্লিক করুন.

CLOUD SHELL

14. Verify you are logged into gcloud with the intended Admin user.

gcloud config list
 

15. Navigate you the asm folder.

cd ${WORKDIR}/asm
 

16. Define your Organization name and workshop ID to be deleted.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. Run the cleanup script as follows.

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}