etcd is 1. replicated: each node in an etcd cluster has full access to the whole data store 2. consistent: every read is going to return the most recent write 3. highly available: no single point of failure and tolerance of network partition 4. fast: the speed upper bound of etcd is the individual node storage speed 5. secured: transport layer SSL 6. simple: http with JSON
@ReflectionOcean2 жыл бұрын
When writing: 1. client makes a write request to the leader node 2. leader node forwards the request to its followers 3. followers make updates to their values 4. followers return success to the leader when values are updated 5. leader updates its own value when majority of the followers are updated successfully 6. leader returns success to the client
@ReflectionOcean2 жыл бұрын
When reading from a follower that's not yet updated: 1. client makes a request to a follower 2. follower forwards the request to the leader 3. leader returns the latest value to the follower 4. follower returns the latest value to the client
@lequocthinh89928 ай бұрын
So every node forward the request to the leader?
@Jamillo4 жыл бұрын
Hi! Around 3:00, is said that the follower node knows it and will forward read requests to the leader. But, wouldn't that stress the leader. I mean, it can't be that simple.
@tomduffin80764 жыл бұрын
I was just thinking exactly the same thing.
@IBMTechnology4 жыл бұрын
Hi Jamillo, thank you for the question and apologies for the delayed response. Do clients have to send requests to the etcd leader? Raft is leader-based; the leader handles all client requests which need cluster consensus. However, the client does not need to know which node is the leader. Any request that requires consensus sent to a follower is automatically forwarded to the leader. Requests that do not require consensus (e.g., serialized reads) can be processed by any cluster member. Source: etcd.io/docs/v3.4.0/faq/
@justinkim72024 жыл бұрын
Well you could say it's a tradeoff for being strongly consistent. It achieves strong consistency by having its leader who has the most recent data to respond to the request. Refer to the raft consensus algorithm which etcd implements.
@blasttrash3 жыл бұрын
good question. This stresses the leader and makes me think why even have followers if for each client request, follower goes back crying to leader for answer. whats the point of having a follower if it always relies on leader and puts too much stress on leader? lol
@r_chauhan3 жыл бұрын
@@blasttrash The followers ensure high availability and the consensus algorithm adds reliability to it. In case the leader goes down, the data is still safe and any other follower can become the leader. The raft consensus mechanism also ensures that only nodes with the most recent "commited" data become the next leader. Hence the redundant data and followers.
@bhaaratsharma60234 жыл бұрын
Precise and to the point introduction. Thank you.
@aliakseibulhak4 жыл бұрын
really love this short explanation videos. thanks you IBM
@insoucyantАй бұрын
Thank You. You explained things amazingly. I hope to see/find more videos from you.
@ReflectionOcean2 жыл бұрын
K8S uses etcd "watch" function to compare configuration (desired) and state (actual)
@ReflectionOcean2 жыл бұрын
The speed upper bound of etcd is the individual node storage speed
@ReflectionOcean2 жыл бұрын
etcd nodes are organized as leader and followers manner
@sbkpilot12 жыл бұрын
a bit confused about this... so if a follower node always has to check with the leader why not directly query the leader node for the info? Does this implicitly mean that to reduce latency it is better to directly query the leader?
@niceperson64122 жыл бұрын
I was also wondering if we always have to ask leader, does it add a lot more burden to the leader node?
@SanjayBudhala11 ай бұрын
periodically the leader sends heartbeats to the follower nodes & sends small impt data with it. This is not a complete explanation a lot is happening behind the bars but answers you query. Follower nodes do query leaders directly using read index protocol but they only do it when they are not sure that they have the latest data.
@vikasvishwakarma3622 Жыл бұрын
The leader will update itself only when the quorum is met i.e. 2/3 or 3/3 nodes(as per configuration) returns positive update.
@kausikcs99132 жыл бұрын
This session is really helpful to get started with the etcd understanding. I have one question though, How long does it take for the changes to reflect to the web applications. Lets say in case of a change to the key-value, can the web application listening to the etcd gets the latest instatly? just like in zookeeper.
@SanjayBudhala11 ай бұрын
No, until the majority of follower nodes are updated with latest data & send the confirmation to the leader node, latest data cant be read.
@cschandragiri2 жыл бұрын
etcd types coordination services are meant for heavy read workloads, wouldn't redirecting read requests to leader to get latest state make it slow. Also, why can't all requests which need strong read consistency go to leader directly instead?
@umutsatrgurbuz88994 жыл бұрын
Thank you for the video, great information, easy to follow.
@vinitsunita2 жыл бұрын
Since etcd persist data on disk, its performance must be tied to disk and it must not be as good as redis in terms of performance of read and write operation because Redis completely holds data in memory as it is inmemory distributed cache
@lindilebangose7667 Жыл бұрын
Both have the exact same functionality, by default etcd stores data in memory and periodically persists snapshots to disk. I don't have the data to comment on performance, but the fact that the k8s team chose it instead should highlight that it does have some advantages over Redis, namely it's consensus strategy that ensure data consistency across all nodes.
@mattvermeer35683 жыл бұрын
Terrific explanation. Thank you.
@IBMTechnology3 жыл бұрын
You're welcome, Matt! 👍
@GauravKumar-sr6bt2 жыл бұрын
If the follower is going to route read requests through leader node (as talked in this video), what is the point of replication and having followers?
@tempofatal Жыл бұрын
fault tolerance
@zhikaicui32172 ай бұрын
@@tempofatal then why the request goes to the follower node in the place for read? Why not directly read leader as leader is anyway requested by the follower node
@ReflectionOcean2 жыл бұрын
etcd stores k8s data for state, configuration and metadata
@jawardsally11865 ай бұрын
As I have understood this, etcd satisfy C and A in CAP theoram. Is it possible?
@fernandopenia70023 жыл бұрын
Perfectly explained. Thank you.
@IBMTechnology3 жыл бұрын
Thanks for watching, Fernando!
@ritu96patel4 жыл бұрын
Great explanation! thanks for sharing
@denysbondarenko7777 ай бұрын
Well explained, thanks 💚
@beneditomarques40623 жыл бұрын
Best explanaiton about etcd!
@intelsc12873 жыл бұрын
Great job! Always tough of public speaking.
@expatExperience Жыл бұрын
Great explanation
@shwetabhshekhar12823 жыл бұрын
Clear and Concise. Thanks a lot.
@medievalogic3 жыл бұрын
So etcd violates CAP? how is this possible?
@ronaldmariah4 жыл бұрын
When the followers had the values 17, 17, 7. And the leader subsequently went down. What's in place for the follower (7) not being elected and replicating a stale value?
@blasttrash3 жыл бұрын
good question. In the video She conveniently changed 7 to 17 when that happened. if a network partition occurred and all "17" nodes went down and only "7" nodes are left, we will have wrong data, this is not explained in this video. Not sure how they tackle this edge case.
@r_chauhan3 жыл бұрын
The raft consensus mechanism has a rule that prevents nodes from voting for nodes with older data than theirs, hence only nodes that have recent data can become a leader.
@DavidHowell-t1p8 ай бұрын
Takes skills to precisely and concisely teach the concepts, all while writing backwards
@nithchea99362 жыл бұрын
Every technology teaching video, there is always positivity in the comment section.
@anoopnegi48864 жыл бұрын
In our etcd cluster we observing that etcd consuming memory and it consumed 2gb after which process killed due to OOM, and without traffic memory stay occupied. Why this issue coming??
@RahulKumar-ed1bt4 жыл бұрын
Its interesting , i would like to see how k8s store data in this , which are collections used for storage inside etcd , can we query etcd in k8s cluster and directly change the data there ? I know that etcd is the brain for k8s cluster but what i see most of the time , it is hidden component for every user and they never connect to etcd , neither query that etc. ! Rather only 1 statement is taught everywhere ok all these states are maintained in etcd and it is single source of truth for anything
@evanturro54582 жыл бұрын
Great video, thanks!
@christopherraymond83823 жыл бұрын
Did I miss the part where she explained what happens when nodes try to rejoin the cluster? She mentioned the case where the mast went down, then never described what happens if/when that node comes back.
@alanwright3762 жыл бұрын
The presentation was high level. The term (session) of a rejoining node will be stale or it will not have an up-to-date commit log, which means it has to be a follower and defer to the current leader. Since followers always have to validate with the leader, it behaves similar to existing followers.
@JusesChrost3 жыл бұрын
The squeeky sound when you write on that board is unnecessory, other than that, perfect video.
@niceperson64122 жыл бұрын
Is this called read repair?
@PurnachandMedisetty Жыл бұрын
5:52 what went down there.
@einfacherkerl32792 жыл бұрын
please describe zookeeper also
@FelipeRodrigues-lj1el2 жыл бұрын
Thank you
@VikramKumar-qo3rg2 жыл бұрын
What happens if the master goes down and based on the votes the slave that has the inconsistent data 7 is elected as master? Is this inconsistency overcome in any way? Or it's not a fair question since the inconsistency would be for a very short period of time and would attain consistency eventually during this upgrade from slave to master process? Anyone who has an idea on this please?
@aakash20202020 Жыл бұрын
voting algorithm is such that 7 will never be elected as leader as it has stale data ..Election can be based on latest updated timestamp of the followers.
@ruslanshamsiev65282 жыл бұрын
Thank you )
@somakkamos2 жыл бұрын
if etcd is so great why not use it as distributed database for all purposes?? whats the catch here?
@Soulseeologia4 жыл бұрын
How much does this cost?
@linxianer124 жыл бұрын
Etcd ? Etcd is free and open source.
@mxmstrj2 жыл бұрын
Are we just going to pretend that she isn't writing everything out backwards better than most people write normally
@mxmstrj2 жыл бұрын
I think they recorded it normally then horizontality flipped the video
@rickharold78844 жыл бұрын
Awesome.
@Edu4Dev4 жыл бұрын
tks for sharing :)
@PaulPetersVids3 жыл бұрын
Uh... quick question. Is she writing backwards?
@guyemry79473 жыл бұрын
right!? I am surprised there aren't more comments about this! That's impressive!
@cesar_zapata3 жыл бұрын
This is how it can be made: kzbin.info/www/bejne/fIraiYKCipmHgc0
@trailblazingfive4 жыл бұрын
tl;dr => etcd is an open source key value data store
@saurabhjha8733 Жыл бұрын
IBM videos are either too broad or too esoteric
@wasim570014 күн бұрын
Effective video ruined by the marker sound , I had a hard time listening to it with focus because of the sound . It was particularly disturbing in my case because i was listening to the video via headphones. Other than that , a good video !!