You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. If your code needs to hold an up-to-date list of objects in memory,
74
+
avoid repeated LIST calls if possible. Instead consider using the
75
+
`Informer` classes that are provided in most Kubernetes client
76
+
libraries. Informers automatically combine LIST and WATCH functionality
77
+
to efficiently maintain an in-memory collection.
78
+
1. If `Informer`s don't suit your needs, try to use the API Server cache
79
+
when LISTing. To use the cache you must supply a `ResourceVersion`.
80
+
Read the [documentation about ResourceVersions](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions) carefully to understand how it will affect the
81
+
freshness of the data you receive.
82
+
1. If you can't use `Informer`s AND you can't use the API Server cache,
83
+
then be sure to [read large lists in chunks](https://kubernetes.io/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks).
84
+
1. Consider the number of instances of your client application which will be running. For instance,
85
+
there is a big difference between having
86
+
just one controller listing objects, versus having demonsets on every node
87
+
doing the same thing. If there will be many instances of your client application
88
+
(either in daemonsets or some other form) you should be particularly careful
89
+
about LIST-related load.
65
90
66
91
### How do you setup clusters for scalability testing?
0 commit comments