★ ServiceMesh Series
1 Istio deployment
1.1 Connecting the tester
Access to the tester server...
1.2 Installing Istio
1.2.1 Downloading Istio through the official website
# Download the latest version of Istio
$ curl -L /downloadIstio | sh -
# Or download the specified version:
$ curl -L /downloadIstio | ISTIO_VERSION=1.8.6 TARGET_ARCH=x86_64 sh -
1.2.2 Checking the installation directory
If version 1.8.6 is installed, we can go directly to this directory and view information about the files in that directory
[CCE~]$ cd /
[CCE~]$ cd /home/work/istio-1.8.6
[CCE~]$ ls -l
total 48
drwxr-x--- 2 work work 4096 Nov 4 15:13 bin # istioctl Client-side binaries
-rw-r--r-- 1 work work 11348 Nov 4 15:13 LICENSE
drwxr-xr-x 5 work work 4096 Nov 4 15:13 manifests
-rw-r----- 1 work work 767 Nov 4 15:13
-rw-r--r-- 1 work work 4183 Nov 4 15:13 productpage
-rw-r--r-- 1 work work 5866 Nov 4 15:13
drwxr-xr-x 19 work work 4096 Nov 16 10:49 samples # sample application (computing)
drwxr-x--- 3 work work 4096 Nov 4 15:20 tools
1.2.3 Environment variable configuration
Use export to generate the environment variable PATH to add the istioctl client to the search path
$ export PATH=$PWD/bin:$PATH
1.2.4 Installing Istio
Installing Istio using istioctl shows that it not only installs the main Istio core program, but also includes the following core components:
- Istiod # Core control surface
- Egress gateways # Outgoing traffic routes
- Ingress gateways # Incoming traffic routing
[CCE~]$ istioctl install --set profile=demo -y
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete
1.2.5 Check for successful installation
The default namespace and pod should have been created correctly (istio-system namespace is created by default when installing istio), so make sure to check here:
[root@k8s-master ~]# kubectl get ns |grep istio
istio-system Active 82m
[root@k8s-master ~]# kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
istio-egressgateway-xxxxxxxxxx-xxxxx 1/1 Running 0 2m33s
istio-ingressgateway-xxxxxxxxxx-xxxxx 1/1 Running 0 2m33s
istiod--xxxxxxxxxx-xxxxx 1/1 Running 0 3m7s
1.2.6 Installing Istio's own sample BookInfo
Because we're testing the book example system, we construct an appropriate namespace name:istio-booking-demo
[CCE~]$ kubectl create namespace istio-booking-demo # Create a namespace
[CCE~]$ kubectl get namespace
NAME STATUS AGE
default Active 23d
icp Active 14d
ingress-nginx Active 23d
istio-booking-demo Active 16s
istio-system Active 22d
kube-node-lease Active 23d
kube-public Active 23d
kube-system Active 23d
local-path-storage Active 23d
1.2.7 Setting up Pod to automatically inject into SideCar
Tagging the namespace instructs Istio to automatically inject the Evnoy SideCard agent when deploying the application.
[CCE~]$ kubectl label namespace istio-booking-demo istio-injection=enabled
namespace/istio-booking-demo labeled
★ Description: This means that all Pods deployed under this namespace (istio-booking-demo) will be automatically injected with the Envoy data plane, and even if no policy is configured, the traffic will still be intercepted by the data plane Envoy and passed through to the service.
1.2.8 Setting up aliases to simplify operations
It is possible to set aliases for operations under certain namespaces to avoid typing too long every time
[CCE~]$ alias kb='kubectl -n istio-booking-demo -o wide' # Setting up aliases
[CCE~]$ alias kb # View Alias
alias kb='kubectl -n istio-booking-demo -o wide'
1.3 Deployment of example applications
1.3.1 Checking the sample catalog
If you look at the address of the BookInfo example that comes with Istio, you can see that there are several directories, as follows:
[CCE~ kube]$ cd /
[CCE~ /]$ cd /home/work/istio-1.8.6/samples/bookinfo/
[CCE~ bookinfo]$ ls -l
total 32
-rwxr-xr-x 1 work work 4029 Nov 4 15:13 build_push_update_images.sh
drwxr-xr-x 2 work work 4096 Nov 16 10:11 networking
drwxr-xr-x 3 work work 4096 Nov 4 15:13 platform
drwxr-xr-x 2 work work 4096 Nov 16 15:04 policy
-rw-r--r-- 1 work work 1306 Nov 4 15:13
drwxr-xr-x 8 work work 4096 Nov 16 15:06 src
-rw-r--r-- 1 work work 6329 Nov 4 15:13
1.3.2 Deployment
Deploy the Bookinfo sample application, applying bookinfo's yaml configuration:
$ kb apply -f platform/kube/
service/details created
serviceaccount/bookinfo-details created
/details-v1 created
service/ratings created
serviceaccount/bookinfo-ratings created
/ratings-v1 created
service/reviews created
serviceaccount/bookinfo-reviews created
/reviews-v1 created
/reviews-v2 created
/reviews-v3 created
service/productpage created
serviceaccount/bookinfo-productpage created
/productpage-v1 created
1.3.3 Examination of deployment results
After the application is deployed, check the deployment of Services and Pods, and you can see that when the Pod is ready, Istio's sidecar Envoy will be packaged and deployed together.
Ensure that all Pods reach this state: the Ready state (READY) has a value of 2/2 and the State (STATUS) has a value of Running.
[CCE~ bookinfo]$ kb get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
details ClusterIP 10.11.12.111 <none> 9080/TCP 28d app=details
productpage ClusterIP 10.11.12.112 <none> 9080/TCP 28d app=productpage
ratings ClusterIP 10.11.12.113 <none> 9080/TCP 28d app=ratings
reviews ClusterIP 10.11.12.114 <none> 9080/TCP 28d app=reviews
[CCE~ bookinfo]$ kb get pods
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
details-v1-xxxxxxxxxx-xxxxx 2/2 Running 0 28d 10.233.67.8 CCE.01 <none> <none>
productpage-v1-xxxxxxxxxx-xxxxx 2/2 Running 0 28d 10.233.67.10 CCE.01 <none> <none>
ratings-v1-xxxxxxxxxx-xxxxx 2/2 Running 0 22d 10.233.67.11 CCE.01 <none> <none>
reviews-v1-xxxxxxxxxx-xxxxx 2/2 Running 0 28d 10.233.68.4 CCE.02 <none> <none>
reviews-v2-xxxxxxxxxx-xxxxx 2/2 Running 0 22d 10.233.68.6 CCE.02 <none> <none>
reviews-v3-xxxxxxxxxx-xxxxx 2/2 Running 0 28d 10.233.67.9 CCE.02 <none> <none>
1.3.4 Verify that the installation was successful
Verify that the installation was successful and see if a page can be read.
[CCE~ bookinfo]$ kubectl -n istio-booking-demo exec "$(kubectl -n istio-booking-demo get pod -l app=ratings -o jsonpath='{.items[0].}')" -c ratings -- curl -s productpage:9080/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>
1.3.5 Configuring Traffic Inbound
Associate the Istio gateway and make sure the configuration file is OK, applying the bookinfo-gateway's yaml configuration:
$ kubectl apply -f networking/
/bookinfo-gateway created
/bookinfo created
$ istioctl analyze
✔ No validation issues found when analyzing namespace: default.
1.3.6 Binding the NodePort
Get the details of ingressgateway, you will find that the EXTERNAL-IP is none, so you can directly change the yaml, bind the port of nodePort, and map it to 8601. verify the access.
[CCE~]$ kb get svc istio-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
istio-ingressgateway NodePort 10.233.32.219 <none> 15021:24534/TCP,80:8601/TCP,443:31159/TCP,31400:23074/TCP,15443:13324/TCP 28d app=istio-ingressgateway,istio=ingressgateway
# ========================================================
[CCE ~]$ kubectl edit svc istio-ingressgateway -n istio-system # After editing type :wq to quit
spec.
clusterIP: 10.233.32.219
externalTrafficPolicy: Cluster
ports: name: status-port
- name: status-port
nodePort: 24534
port: 15021
protocol: TCP
targetPort: 15021
- name: http2
nodePort: 8601
port: 80
protocol: TCP
targetPort: 8080
- name: https
nodePort: 31159
protocol: TCP targetPort: 8080 name: https nodePort: 31159
protocol: TCP
targetPort: 8443
- name: tcp
nodePort: 23074
port: 31400
protocol: TCP
targetPort: 31400
- name: tls
nodePort: 13324
port: 15443
protocol: TCP
targetPort: 15443
selector: istio-ingressgateway
app: istio-ingressgateway
istio: ingressgateway
sessionAffinity: None
type: NodePort
1.4 Installation of the instrument panel
Once the application services are installed, many related dashboards need to be installed for visualization and management. This includes kiali monitoring , k8s dashboard, Grafana (BI reporting), Jaeger Trace system
1.4.1 Kiali dashboard installation
[CCE~ samples]$ cd samples/addons
[CCE~ addons]$ ls -l # embody4visualization system：grafana、jaeger、kiali、prometheus
total 304
drwxr-xr-x 2 work work 4096 Nov 4 15:13 extras
-rw-r--r-- 1 work work 240054 Nov 4 15:13
-rw-r--r-- 1 work work 2317 Nov 4 15:13
-rw-r--r-- 1 work work 35080 Nov 4 15:13
-rw-r--r-- 1 work work 13250 Nov 4 15:13
-rw-r--r-- 1 work work 5186 Nov 4 15:13
# mountingKialiand other plug-ins，Waiting for deployment to complete！
$ kubectl apply -f samples/addons
$ kubectl rollout status deployment/kiali -n istio-system
Waiting for deployment "kiali" rollout to finish: 0 of 1 updated replicas are available...
deployment "kiali" successfully rolled out
# Accessing the Dashboard，ctl+c Exit current read
[CCE~ addons]$ istioctl dashboard kiali
http://localhost:20001/kiali
[CCE~ addons]$ istioctl dashboard grafana
http://localhost:3000
[CCE~ addons]$ istioctl dashboard jaeger
http://localhost:16686
[CCE~ addons]$ istioctl dashboard prometheus
http://localhost:9090
# The actual external access address is the same as the 1.3.6 Consistency of approach
# First, check the entire cluster for allnamespacepresent situation
$ kb get service --all-namespaces
# Look up specific service information
$ kb get service --all-namespaces | grep grafana
# carry outnodePartport bonding
$ kubectl edit svc grafana -n istio-system # nodePort的port bonding 8663
$ kubectl edit svc kiali -n istio-system # nodePort的port bonding 8661
$ kubectl edit svc prometheus -n istio-system # nodePort的port bonding 8664
$ kubectl edit svc tracing -n istio-system # nodePort的port bonding 8665,jaeger
Note: Official deployment steps are also provided, you can refer to the following Build steps
2 Introduction to Istio capabilities
2.1 Brief introduction
Istio has a wealth of traffic management capabilities, you can refer to the official provision of a wealth of test cases, including, but not limited to, request routing configuration, fault injection, traffic diversion, TCP traffic diversion, request timeout, meltdowns, traffic mirroring, geographic load balancing, Ingress+Egress
2.2 Request Routing Configuration
2.2.1 Request Route Scheduling
There is a common need in request routing: it is to make different user groups see different information, for example, VIP users and ordinary users see different content, and the discount price is different; or for example, logged-in users and non-logged-in users see different information.
2.2.1 Route initialization
Applying virtual-service-all-v1 first will direct all request traffic to the version 1 service (i.e., the Virtual Service versions all point to v1).
Application yaml
[CCE ~]$ cd /
[CCE /]$ cd /home/work/istio-1.8.6/samples/bookinfo/
[CCE bookinfo]$ kubectl -n istio-booking-demo apply -f networking/
/productpage unchanged
/reviews unchanged
/ratings unchanged
/details unchanged
Routing Rules
[CCE bookinfo]$ kb get virtualservices -o yaml # View allvirtualservices
[CCE bookinfo]$ kb get destinationrules -o yaml # View alldestinationrules
[CCE bookinfo]$ kb get virtualservices reviews -o yaml # ferret outreviews(used form a nominal expression)virtualservices
apiVersion: /v1beta1
kind: VirtualService
metadata: # The data doesn't matter.，This side is blocked.
spec:
hosts:
- reviews
http:
- route:
- destination: # directional reviews 服务(used form a nominal expression)v1releases
host: reviews
subset: v1
[CCE bookinfo]$ kb get virtualservices ratings -o yaml # ferret outratings(used form a nominal expression)virtualservices
apiVersion: /v1beta1
kind: VirtualService
metadata: # The data doesn't matter.，This side is blocked.
spec:
hosts:
- ratings
http:
- route:
- destination: # directional ratings 服务(used form a nominal expression)v1releases
host: ratings
subset: v1
Open the interface, you will find that no matter how much you refresh the page, it will not show the star rating, that's because the reviews: v1 version will not access the star rating service.
2.2.2 User identity-based routing
Make a tweak so that traffic for the Jason user is forwarded to reviews:v2, by requesting that the end-user in the Header have the specific person name Jason.
[CCE bookinfo]$ kubectl -n istio-booking-demo apply -f networking/
/reviews configured
[CCE bookinfo]$ kb get virtualservices reviews -o yaml
apiVersion: /v1beta1
kind: VirtualService
metadata: # The data doesn't matter.，This side is blocked.
spec:
hosts:
- reviews
http:
- match:
- headers: # headerharbor (i.e. in the middle of sth)end-userand the value isjasonThe user's traffic goesv2releases，Other walksv1releases
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
Compare to 2.2.1, you will find the difference, this side of the reviews service's under a specific jason user will go to the v2 version, the effect is as follows, you can see the ratings service's star ratings now.
- productpage → reviews:v2 → ratings (for jason users)
- productpage → reviews:v1 (Other users)
2.2.3 Clearing the application Virtual Service
If you don't need the rule you can just delete it. After deleting it, all the routing rules are gone, and only the SideCar interception between individual Pods remains.
[CCE bookinfo]$ kubectl -n istio-booking-demo delete -f networking/
3 Summary
This article describes the deployment and simple routing implementation of Istio, and subsequent chapters will explore more exciting aspects.
- Complex Route Scheduling
- fault injection
- flow transfer
- TCP Traffic Transfer
- Request timeout
- fuse
- traffic mirroring
- geographic load balancing
- Ingress+Egress
- ServiceEntry